[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860

--- Comment #36 from David Binderman  ---
(In reply to Martin Liška from comment #35)
> Btw. can you run the failing compilation in gdb and list where exactly it
> fails (which option name is different)?

Shown previous runs indicate the first test in routine cl_optimization_compare.
So field x_help_flag.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860

--- Comment #35 from Martin Liška  ---
Btw. can you run the failing compilation in gdb and list where exactly it fails
(which option name is different)?

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860

--- Comment #34 from Martin Liška  ---
I don't have to do anything special in order to get pre-processed source file:

$ gcc pr88876.c -freport-bug 
pr88876.c:10:1: internal compiler error: ‘global_options’ are modified in local
context
   10 | int c() {return 0;}
  | ^~~
0xce038b cl_optimization_compare(gcc_options*, gcc_options*)
/dev/shm/objdir/gcc/options-save.c:9822
0x8c4f88 handle_optimize_attribute
/home/marxin/Programming/gcc/gcc/c-family/c-attribs.c:4475
0x7d4ee7 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/attribs.c:714
0x7f1625 start_function(c_declspecs*, c_declarator*, tree_node*)
/home/marxin/Programming/gcc/gcc/c/c-decl.c:9177
0x84bdb7 c_parser_declaration_or_fndef
/home/marxin/Programming/gcc/gcc/c/c-parser.c:2434
0x855453 c_parser_external_declaration
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1773
0x855f51 c_parser_translation_unit
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1646
0x855f51 c_parse_file()
/home/marxin/Programming/gcc/gcc/c/c-parser.c:21822
0x8ae88b c_common_parse_file()
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/cc8jx9U7.out file, please attach this to
your bugreport.

[Bug tree-optimization/95804] [11 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1323 since r11-1565-g2c0069fafb53ccb7

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95804

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
Summary|ice in  |[11 Regression] ICE in
   |generate_code_for_partition |generate_code_for_partition
   |, at|, at
   |tree-loop-distribution.c:13 |tree-loop-distribution.c:13
   |23  |23 since
   ||r11-1565-g2c0069fafb53ccb7
 Blocks||26163
 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Started with r11-1565-g2c0069fafb53ccb7. I see it failing in blender SPEC
benchmark.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug fortran/95880] [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> This is due to a change in GCC11 that have been back ported to GCC9 and 10
> (pr94397?).

It is NOT pr94397.

[Bug middle-end/95886] suboptimal memcpy with embedded zero bytes

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95886

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95887

--- Comment #2 from Martin Sebor  ---
See also pr95887 for a related problem with memcmp.

[Bug middle-end/95886] suboptimal memcpy with embedded zero bytes

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95886

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Last reconfirmed||2020-06-24

--- Comment #1 from Martin Sebor  ---
I'm testing a fix.

[Bug fortran/95828] ICE in resolve_select_rank, at fortran/resolve.c:9774

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95828

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch posted: https://gcc.gnu.org/pipermail/fortran/2020-June/054604.html

[Bug middle-end/95887] New: suboptimal memcmp with embedded zero bytes

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95887

Bug ID: 95887
   Summary: suboptimal memcmp with embedded zero bytes
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to pr95886, the memcmp expansion into compare-by-pieces is less than
optimal for sequences containing embedded null bytes.  For example, in the test
case below, the memcmp call in f() is expanded into what looks like a more
efficient sequence than the equivalent memcmp call in g().  The only difference
between the two is that the former copies a sequence of non-zero bytes while
among the bytes copied by the latter is a null byte.  Clang emits the same code
for g() as GCC does for f().

I believe the root cause of the problem in both cases is working with
nul-terminated strings (using the result of c_getstr() without the size of what
it points to) instead of with arbitrary byte sequences.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout -o/dev/stdout
z.c
const char a[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
const char b[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };

int f (void *d)
{
  return __builtin_memcmp (d, a, 8);
}

int g (void *d)
{
  return __builtin_memcmp (d, b, 8);
}


.file   "z.c"
.text

;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=2)

f (void * d)
{
  int _3;

   [local count: 1073741824]:
  _3 = __builtin_memcmp (d_2(D), &a, 8); [tail call]
  return _3;

}


.p2align 4
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
movl$8, %edx
movl$a, %esi
jmp memcmp
.cfi_endproc
.LFE0:
.size   f, .-f

;; Function g (g, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=3)

g (void * d)
{
  int _3;

   [local count: 1073741824]:
  _3 = __builtin_memcmp (d_2(D), &b, 8); [tail call]
  return _3;

}


.p2align 4
.globl  g
.type   g, @function
g:
.LFB1:
.cfi_startproc
movzbl  (%rdi), %eax
ret
.cfi_endproc
.LFE1:
.size   g, .-g
.globl  b
.section.rodata
.align 8
.type   b, @object
.size   b, 8
b:
.string ""
.ascii  "\001\002\003\004\005\006\007"
.globl  a
.align 8
.type   a, @object
.size   a, 8
a:
.ascii  "\001\002\003\004\005\006\007\b"
.ident  "GCC: (GNU) 10.1.1 20200527"
.section.note.GNU-stack,"",@progbits

[Bug middle-end/95189] [10/11 Regression] memcmp being wrongly stripped like strcmp

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189

--- Comment #7 from Martin Sebor  ---
The following is a more straightforward test case that's also miscompiled to
return zero:

  int main ()
  { 
char a[] = "\0abc";

return __builtin_memcmp (a, "\0\0\0\0", 4);
  }

main:
.LFB0:
.cfi_startproc
xorl%eax, %eax
ret

There seems to a series of mistakes that led to this bug.  First, in the
original test case, the initializer for the const float array of all zeros is
just a single null byte, regardless of how big the array is.  c_getstr()
returns the empty string for such an array and sets *STRLEN to 1.  As I
mentioned in comment #4, this is very confusing given that the function can be
called for non-strings and that the comment suggests embedded nuls are
reflected in the STRLEN result.

The c_getstr() caller that ultimately interprets this result wrong is
inline_expand_builtin_string_cmp() in builtins.c.  The comment above the
function  reads:

/* Inline expansion a call to str(n)cmp, with result going to
   TARGET if that's convenient.
   If the call is not been inlined, return NULL_RTX.  */

but it's (also) called from expand_builtin_memcmp(), so yet again, the comment
is incorrect or at best misleading.  The function then implements the correct
behavior for strncmp() but not for memcmp().  The miscompilation was apparently
introduced by r272993, most likely because of the misleading function name. 
The call to inline_expand_builtin_string_cmp() from expand_builtin_memcmp() was
introduced in r262636.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug fortran/95828] ICE in resolve_select_rank, at fortran/resolve.c:9774

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95828

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
This one is needed to match the resolve.c part:

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 8063fcad295..b011634792e 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6496,7 +6496,7 @@ static void
 select_rank_set_tmp (gfc_typespec *ts, int *case_value)
 {
   char name[2 * GFC_MAX_SYMBOL_LEN];
-  char tname[GFC_MAX_SYMBOL_LEN];
+  char tname[GFC_MAX_SYMBOL_LEN + 7];
   gfc_symtree *tmp;
   gfc_symbol *selector = select_type_stack->selector;
   gfc_symbol *sym;

Taking.

[Bug middle-end/95886] New: suboptimal memcpy with embedded zero bytes

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95886

Bug ID: 95886
   Summary: suboptimal memcpy with embedded zero bytes
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing the fix for pr95189 I noticed that the memcpy expansion into
copy-by-pieces is less than optimal for sequences containing embedded null
bytes.  For example, in the test case below, the memcpy call in f() is expanded
into what looks like a more efficient sequence than the equivalent memcpy call
in g().  The only difference between the two is that the former copies a
sequence of non-zero bytes while among the bytes copied by the latter is a null
byte.  Clang emits the same code for g() as GCC does for f().

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout -o/dev/stdout
z.c
const char a[10] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
const char b[10] = { 0, 1, 2, 3, 4, 5, 6, 7, 8 };

void f (void *d)
{
  __builtin_memcpy (d, a, 9);   // optimal
}

void g (void *d)
{
  __builtin_memcpy (d, b, 9);   // suboptimal
}


.file   "z.c"
.text

;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=2)

f (void * d)
{
   [local count: 1073741824]:
  __builtin_memcpy (d_2(D), &a, 9); [tail call]
  return;

}


.p2align 4
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
movabsq $578437695752307201, %rax
movb$9, 8(%rdi)
movq%rax, (%rdi)
ret
.cfi_endproc
.LFE0:
.size   f, .-f

;; Function g (g, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=3)

g (void * d)
{
   [local count: 1073741824]:
  __builtin_memcpy (d_2(D), &b, 9); [tail call]
  return;

}


.p2align 4
.globl  g
.type   g, @function
g:
.LFB1:
.cfi_startproc
movqb(%rip), %rax
movq%rax, (%rdi)
movzbl  b+8(%rip), %eax
movb%al, 8(%rdi)
ret
.cfi_endproc
.LFE1:
.size   g, .-g
.globl  b
.section.rodata
.align 8
.type   b, @object
.size   b, 10
b:
.string ""
.string "\001\002\003\004\005\006\007\b"
.globl  a
.align 8
.type   a, @object
.size   a, 10
a:
.string "\001\002\003\004\005\006\007\b\t"
.ident  "GCC: (GNU) 10.1.1 20200527"
.section.note.GNU-stack,"",@progbits

[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94954

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Will Schmidt :

https://gcc.gnu.org/g:58b475a2233630b1737bbdab986f08510d62cd3a

commit r11-1643-g58b475a2233630b1737bbdab986f08510d62cd3a
Author: Will Schmidt 
Date:   Wed Jun 24 15:28:24 2020 -0500

[PATCH, PR target/94954] Fix wrong codegen for vec_pack_to_short_fp32()
builtin

Hi,
  Fix codegen for builtin vec_pack_to_short_fp32.  This includes adding
a define_insn for xvcvsphp, and adding a new define_expand for
convert_4f32_8f16.

2020-06-24  Will Schmidt  

PR target/94954

gcc
* config/rs6000/altivec.h (vec_pack_to_short_fp32): Update.
* config/rs6000/altivec.md (UNSPEC_CONVERT_4F32_8F16): New unspec.
(convert_4f32_8f16): New define_expand
* config/rs6000/rs6000-builtin.def (convert_4f32_8f16): New builtin
define
and overload.
* config/rs6000/rs6000-call.c (P9V_BUILTIN_VEC_CONVERT_4F32_8F16):
New
overloaded builtin entry.
* config/rs6000/vsx.md (UNSPEC_VSX_XVCVSPHP): New unspec.
(vsx_xvcvsphp): New define_insn.

gcc/testsuite
* gcc.target/powerpc/builtins-1-p9-runnable.c: Update.

[Bug fortran/95880] [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-24
   Priority|P3  |P4
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
This is due to a change in GCC11 that have been back ported to GCC9 and 10
(pr94397?).

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860

--- Comment #33 from David Binderman  ---
(In reply to Martin Liška from comment #32)
> Thank you very much. I'll wait for a test-case by you ;)

I have had a go, but I cannot generate an intermediate file.

I've tried various ways to get options-save.c to crash.
This is my most recent effort:

struct S {
int a;
int b;
};

void
cl_optimization_compare (gcc_options *ptr1, gcc_options *ptr2)
{
  if (ptr1->x_help_flag != ptr2->x_help_flag) {
S * p = 0;
fprintf( stderr, "%d\n", p->a);
internal_error ("% are modified in local context");
  }

I also tried integer division by zero, which didn't seem to work.

If anyone has any better ideas on generating a crash, I would be glad 
to hear about them.

[Bug c++/95510] [coroutines] ICE with consteval operator co_await

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95510

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #2)
> This was fixed by r11-1455-g14c831f5ef61
> (but not sure if there's a plan to back-port to 10.2 yet).

back ported as r10-8328-g9014cb7c1695.
therefore fixed for master and 10.2

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174

--- Comment #11 from Vladimir Makarov  ---
(In reply to Tamar Christina from comment #10)
> Hi Vlad,
> 
> Just curious if you had a chance to think about an approach to this that
> would be acceptable.

  Sorry for not working on this issue more although I thought about the problem
for some time w/o finding any possible small code changes could solve the
problem.

  I just expressed my point of view to the bottom-up approach.  If somebody
implements any new RA approach which at least does not hurt credible benchmarks
(e.g. SPEC) and improve some benchmarks and does not complicate existing RA too
much, nobody will have legitimate arguments not to include the new code into
GCC.

  I think that may be for some cases bottom-up approach could work better. 
Probably this is code for number crunching (with a lot of loop iterations). 
For some cases top-down approach works better for loops with smaller number
iterations  (e.g. most loops in GCC itself).

  Simply, I tried already bottom-up approach and don't want to work on this
again because if it does not work I will have to throw this work off again.

  I am mostly in maintenance mode for GCC RA, don't want to work on big RA
changes.  This work would be also very hard to sell to my management.

  If somebody implements bottom-up RA as an optional (or default if it is
better on SPEC) algorithm and this improves some benchmarks, I will not object.
 The work I think would take several months for a person familiar with RA.

[Bug fortran/95689] [8/9/10/11 Regression] ICE in check_sym_interfaces, at fortran/interface.c:2015

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95689

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:e3d976ae009b873596b47961869b7cdfc41d7e67

commit r9-8696-ge3d976ae009b873596b47961869b7cdfc41d7e67
Author: Harald Anlauf 
Date:   Wed Jun 24 22:44:11 2020 +0200

Revert "PR fortran/95689 - ICE in check_sym_interfaces, at
fortran/interface.c:2015"

With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer.  We now check that we do not
exceed the enlarged buffer size.

gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.

gcc/testsuite/
PR fortran/95689
* gfortran.dg/pr95689.f90: New test.

(reverts the cherry-pick from commit
62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6)

[Bug middle-end/65832] Inefficient vector construction

[gabravier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65832

Gabriel Ravier  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com

--- Comment #10 from Gabriel Ravier  ---
Someone might want to look at this, from what I can see it looks like the first
few examples are now optimized optimally but I can't say for sure that the
later examples are optimized optimally in the same way (it looks like some of
them at least somewhat ideally optimized but some of them are... badly
optimized, to say the least).

[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577

Alexandre Oliva  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #10 from Alexandre Oliva  ---
Fixed

[Bug fortran/95689] [8/9/10/11 Regression] ICE in check_sym_interfaces, at fortran/interface.c:2015

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95689

--- Comment #9 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:e1edfe597d9157b8b9b61c4677b38730a9a59936

commit r8-10327-ge1edfe597d9157b8b9b61c4677b38730a9a59936
Author: Harald Anlauf 
Date:   Wed Jun 24 22:33:11 2020 +0200

Revert "PR fortran/95689 - ICE in check_sym_interfaces, at
fortran/interface.c:2015"

With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer.  We now check that we do not
exceed the enlarged buffer size.

gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.

gcc/testsuite/
PR fortran/95689
* gfortran.dg/pr95689.f90: New test.

(reverts the cherry-pick from commit
62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6)

[Bug testsuite/95416] Several gcc.misc-tests/outputs.exp tests FAIL

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95416

Alexandre Oliva  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Alexandre Oliva  ---
Fixed

[Bug testsuite/95577] Tcl error with testsuite/gcc.misc-tests/outputs.exp on darwin

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95577

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:ef6506e23691a72e1e724977e8ee8b9f3db74015

commit r11-1642-gef6506e23691a72e1e724977e8ee8b9f3db74015
Author: Alexandre Oliva 
Date:   Wed Jun 24 17:20:49 2020 -0300

outputs.exp: conditionals for split-dwarf and lto plugin

This patch introduces support for conditionals (and expr) expansions
to file lists in proc outest in outputs.exp.

The conditionals machinery is now used to guard files that are only
created by the LTO plugin, or when not using the LTO plugin.

It is also used to avoid special-casing .dwo files: the condition of
when they're expected is now encoded in the list.

Furthermore, the -g flag, that used to be specified along with
$gsplit_dwarf, is now moved into $gsplit_dwarf, so that we don't
compile with -g if -gsplit-dwarf is not needed.  This avoids having to
deal with .dSYM directories.

Further removing special cases, $aout is now dealt with in a more
general way, using expr to perform variable/string expansion.


for  gcc/testsuite/ChangeLog

PR testsuite/95416
PR testsuite/95577
* gcc.misc-tests/outputs.exp (gsplit_dwarf): Move -g into it.
(outest): Introduce conditionals and string/variable/expr
expansion.  Drop special-casing of $aout and .dwo.
(gspd): New conditional.  Guard all .dwo files with it.
(ltop): New conditional.  Guard files created by the LTO
plugin with it.  Guard files created by fat LTO compilation
with its negation.  Add a few -fno-use-linker-plugin tests
guarded by it.

[Bug testsuite/95416] Several gcc.misc-tests/outputs.exp tests FAIL

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95416

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:ef6506e23691a72e1e724977e8ee8b9f3db74015

commit r11-1642-gef6506e23691a72e1e724977e8ee8b9f3db74015
Author: Alexandre Oliva 
Date:   Wed Jun 24 17:20:49 2020 -0300

outputs.exp: conditionals for split-dwarf and lto plugin

This patch introduces support for conditionals (and expr) expansions
to file lists in proc outest in outputs.exp.

The conditionals machinery is now used to guard files that are only
created by the LTO plugin, or when not using the LTO plugin.

It is also used to avoid special-casing .dwo files: the condition of
when they're expected is now encoded in the list.

Furthermore, the -g flag, that used to be specified along with
$gsplit_dwarf, is now moved into $gsplit_dwarf, so that we don't
compile with -g if -gsplit-dwarf is not needed.  This avoids having to
deal with .dSYM directories.

Further removing special cases, $aout is now dealt with in a more
general way, using expr to perform variable/string expansion.


for  gcc/testsuite/ChangeLog

PR testsuite/95416
PR testsuite/95577
* gcc.misc-tests/outputs.exp (gsplit_dwarf): Move -g into it.
(outest): Introduce conditionals and string/variable/expr
expansion.  Drop special-casing of $aout and .dwo.
(gspd): New conditional.  Guard all .dwo files with it.
(ltop): New conditional.  Guard files created by the LTO
plugin with it.  Guard files created by fat LTO compilation
with its negation.  Add a few -fno-use-linker-plugin tests
guarded by it.

[Bug c++/95672] ICE in cxx_incomplete_type_diagnostic, at cp/typeck2.c:584

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95672

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #7 from Jason Merrill  ---
Fixed for GCC 11.

[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95719

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Jason Merrill  ---
Fixed for 10.2/11.

[Bug c++/95672] ICE in cxx_incomplete_type_diagnostic, at cp/typeck2.c:584

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95672

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:11a751ff77fba92de77b099ec5e1896d3a99d482

commit r11-1641-g11a751ff77fba92de77b099ec5e1896d3a99d482
Author: Nicholas Krause 
Date:   Tue Jun 23 15:47:37 2020 -0400

c++: Handle bad pack expansion in base list. [PR96752]

This fixes PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICEs on diagnosing
incomplete template pack expansion cases.

Tested on powerpc64le-unknown-linux-gnu.

gcc/cp/ChangeLog:

PR c++/95672
* typeck2.c (cxx_incomplete_type_diagnostic): Add missing
TYPE_EXPANSION_PACK check for diagnosing incomplete types in
cxx_incomplete_type_diagnostic.

gcc/testsuite/ChangeLog:

PR c++/95672
* g++.dg/template/pr95672.C: New test.

Signed-off-by: Nicholas Krause 

[Bug c++/95813] Making static member function a coroutine may cause "defined but not used" warning for destroy(frame*) function

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95813

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:1e5da6a02fec8aa84bb00966282f420cb70fe4f0

commit r11-1640-g1e5da6a02fec8aa84bb00966282f420cb70fe4f0
Author: Iain Sandoe 
Date:   Wed Jun 24 18:48:33 2020 +0100

coroutines: Copy attributes to the outlined functions [PR95518,PR95813]

We had omitted the copying of function attributes, we now copy
the used, alignment, section values from the original decal and
the complete set of function attributes.  It is likely that
some function attributes don't really make sense for coroutines,
but that can be disgnosed separately. Also mark the outlined
functions as artificial, since they are; some diagnostic
processing tests this.

gcc/cp/ChangeLog:

PR c++/95518
PR c++/95813
* coroutines.cc (act_des_fn): Copy function
attributes onto the outlined coroutine helpers.

gcc/testsuite/ChangeLog:

PR c++/95518
PR c++/95813
* g++.dg/coroutines/pr95518.C: New test.
* g++.dg/coroutines/pr95813.C: New test.

[Bug c++/95518] [coroutines] [[maybe_unused]] does not propagate to actor() and destroy()

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95518

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:1e5da6a02fec8aa84bb00966282f420cb70fe4f0

commit r11-1640-g1e5da6a02fec8aa84bb00966282f420cb70fe4f0
Author: Iain Sandoe 
Date:   Wed Jun 24 18:48:33 2020 +0100

coroutines: Copy attributes to the outlined functions [PR95518,PR95813]

We had omitted the copying of function attributes, we now copy
the used, alignment, section values from the original decal and
the complete set of function attributes.  It is likely that
some function attributes don't really make sense for coroutines,
but that can be disgnosed separately. Also mark the outlined
functions as artificial, since they are; some diagnostic
processing tests this.

gcc/cp/ChangeLog:

PR c++/95518
PR c++/95813
* coroutines.cc (act_des_fn): Copy function
attributes onto the outlined coroutine helpers.

gcc/testsuite/ChangeLog:

PR c++/95518
PR c++/95813
* g++.dg/coroutines/pr95518.C: New test.
* g++.dg/coroutines/pr95813.C: New test.

[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95719

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:554eb7d2e1ef5660d6a8e1c12ee1d751a70bbf31

commit r10-8363-g554eb7d2e1ef5660d6a8e1c12ee1d751a70bbf31
Author: Jason Merrill 
Date:   Tue Jun 23 21:25:21 2020 -0400

c++: Fix ICE with using and virtual function. [PR95719]

conversion_path points to the base where we found the using-declaration,
not
where the function is actually a member; look up the actual base.  And then
maybe look back to the derived class if the base is primary.

gcc/cp/ChangeLog:

PR c++/95719
* call.c (build_over_call): Look up the overrider in base_binfo.
* class.c (lookup_vfn_in_binfo): Look through BINFO_PRIMARY_P.

gcc/testsuite/ChangeLog:

PR c++/95719
* g++.dg/tree-ssa/final4.C: New test.

(cherry picked from commit 7d6baf68fe22b6ef5b1d6fabbef97c0e1b4d7abf)

[Bug target/95885] New: LOCAL_DECL_ALIGNMENT macro documentation is incorrect.

[skpgkp2 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95885

Bug ID: 95885
   Summary: LOCAL_DECL_ALIGNMENT macro documentation is incorrect.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp2 at gmail dot com
  Target Milestone: ---
Target: x86_64-*-* i?86-*-*

LOCAL_DECL_ALIGNMENT Macro documentation

 1172 @defmac LOCAL_DECL_ALIGNMENT (@var{decl})
 1173 If defined, a C expression to compute the alignment for a local
 1174 variable @var{decl}.
 1175 
 1176 If this macro is not defined, then
 1177 @code{LOCAL_ALIGNMENT (TREE_TYPE (@var{decl}), DECL_ALIGN (@var{decl}))}
 1178 is used.
 1179 
 1180 One use of this macro is to increase alignment of medium-size data to
 1181 make it all fit in fewer cache lines.
 1182 
 1183 If the value of this macro has a type, it should be an unsigned type.
 1184 @end defmac

This macro not only increases alignment but also decreases(-m32
-mpreferred-stack-boundary=2) depending on condition.

[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95719

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:7d6baf68fe22b6ef5b1d6fabbef97c0e1b4d7abf

commit r11-1637-g7d6baf68fe22b6ef5b1d6fabbef97c0e1b4d7abf
Author: Jason Merrill 
Date:   Tue Jun 23 21:25:21 2020 -0400

c++: Fix ICE with using and virtual function. [PR95719]

conversion_path points to the base where we found the using-declaration,
not
where the function is actually a member; look up the actual base.  And then
maybe look back to the derived class if the base is primary.

gcc/cp/ChangeLog:

PR c++/95719
* call.c (build_over_call): Look up the overrider in base_binfo.
* class.c (lookup_vfn_in_binfo): Look through BINFO_PRIMARY_P.

gcc/testsuite/ChangeLog:

PR c++/95719
* g++.dg/tree-ssa/final4.C: New test.

[Bug c++/95883] New: Attributes on lambdas appear to be parsed in the wrong place

[drewb at valvesoftware dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95883

Bug ID: 95883
   Summary: Attributes on lambdas appear to be parsed in the wrong
place
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drewb at valvesoftware dot com
  Target Milestone: ---

Created attachment 48782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48782&action=edit
Artificial source test case

In 90333 there's a discussion of where attributes on lambdas should be
processed.  In 8.3 they were handled after the declarator but that regressed in
9.  90333 says that it was fixed to work properly after the declarator and that
they also added support for attributes before the declarator.  However in
testing against 9.3 attributes after the declarator do not work so it does not
look like the fix is working.

cppreference says that lambda attributes should come after the declarator. 
Testing with godbolt it looks like attributes after the declarator are the
common case (for example clang works on the test case and fails with attributes
before the declarator).

[Bug c++/95820] [10/11 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720

--- Comment #7 from Alexandre Oliva  ---
now, if it is from the board config file, maybe it had better be moved to
ldflags or libs; both of them undergo some -Wl, treatment of object files and
libs already.

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720

--- Comment #6 from Alexandre Oliva  ---
In case that's from some board config file, I suggest prefixing it with -Wl, so
that it doesn't count as an additional input.

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720

--- Comment #5 from Alexandre Oliva  ---
that's because of the second input gcc_tg.o

can you tell where that comes from?

[Bug fortran/95827] ICE in gfc_get_string, at fortran/iresolve.c:70

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95827

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:a16d0924f18046704ef9a4b6d9593718594677f1

commit r11-1634-ga16d0924f18046704ef9a4b6d9593718594677f1
Author: Harald Anlauf 
Date:   Wed Jun 24 21:03:47 2020 +0200

PR fortran/95827 - Buffer overflows with submodules and coarrays

With submodules and coarrays, name mangling results in long internal
symbols.  Enlarge internal buffer.

gcc/fortran/
PR fortran/95827
* iresolve.c (gfc_get_string): Enlarge internal buffer used in
generating the mangled name.

[Bug fortran/95882] [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95882

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

Related, with different backtraces :


$ cat z2.f90
module m
   character(((0)/0)) :: c = '123456789'
end


$ cat z3.f90
subroutine s(c)
   character(((0)/0)) :: c
end


$ cat z4.f90
program p
   character(((0)/0)) :: c
   common /x/ c
end


$ cat z5.f90
program p
   character(((0)/0)) :: c = '123456789'
   common c
end

[Bug fortran/95882] New: [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95882

Bug ID: 95882
   Summary: [9/10/11 Regression] ICE in gfc_get_derived_type, at
fortran/trans-types.c:2729
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20200517 and 20200524 :


$ cat z1.f90
module m
   type t
  character(((0)/0)) :: c
   end type
end


$ gfortran-11-20200517 -c z1.f90
z1.f90:3:22:

3 |   character(((0)/0)) :: c
  |  1
Error: Division by zero at (1)


$ gfortran-11-20200621 -c z1.f90
f951: internal compiler error: in gfc_get_derived_type, at
fortran/trans-types.c:2729
0x784843 gfc_get_derived_type(gfc_symbol*, int)
../../gcc/fortran/trans-types.c:2729
0x784b68 gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc/fortran/trans-types.c:1166
0x784dbe gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2247
0x729616 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1769
0x72c888 gfc_create_module_variable
../../gcc/fortran/trans-decl.c:5302
0x6ebde2 do_traverse_symtree
../../gcc/fortran/symbol.c:4162
0x72d08b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5801
0x707ca4 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2238
0x6b4b01 translate_all_program_units
../../gcc/fortran/parse.c:6294
0x6b4b01 gfc_parse_file()
../../gcc/fortran/parse.c:6546
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95881] New: [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95881

Bug ID: 95881
   Summary: [9/10/11 Regression] ICE in resolve_symbol, at
fortran/resolve.c:15175
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r7, with a missing attribute :


$ cat z1.f90
program p
   type t
  real, allocatable :: a[:]
   end type
   class(t) :: x
   allocate (x%a[*])
end


$ cat z2.f90
subroutine s(x)
   type t
  real, allocatable :: a[:]
   end type
   block
  class(t) :: x
  allocate (x%a[*])
   end block
end


$ gfortran-6 -c z1.f90 -fcoarray=lib
z1.f90:5:16:

class(t) :: x
1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer


$ gfortran-11-20200621 -c z1.f90 -fcoarray=single
z1.f90:5:16:

5 |class(t) :: x
  |1
Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer


$ gfortran-11-20200621 -c z1.f90 -fcoarray=lib
f951: internal compiler error: Segmentation fault
0xbce57f crash_signal
../../gcc/toplev.c:328
0x6cda25 resolve_symbol
../../gcc/fortran/resolve.c:15175
0x6ebde2 do_traverse_symtree
../../gcc/fortran/symbol.c:4162
0x6d1094 resolve_types
../../gcc/fortran/resolve.c:17175
0x6cc7ac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17290
0x6b48ec resolve_all_program_units
../../gcc/fortran/parse.c:6246
0x6b48ec gfc_parse_file()
../../gcc/fortran/parse.c:6493
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95880] New: [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95880

Bug ID: 95880
   Summary: [9/10/11 Regression] ICE in gfc_add_type, at
fortran/symbol.c:2030
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r8, started between 20200517 and 20200524 :


$ cat z1.f90
module m
end
block data
   use m
   integer m
end block data


$ cat z5.f90
module m
   type t
   end type
end
block data
   use m
   type(t) m
end block data


$ gfortran-11-20200517 -c z1.f90
z1.f90:5:12:

5 |integer m
  |1
Error: Symbol 'm' at (1) cannot have a type


$ gfortran-11-20200621 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbce57f crash_signal
../../gcc/toplev.c:328
0x6f02bc gfc_add_type(gfc_symbol*, gfc_typespec*, locus*)
../../gcc/fortran/symbol.c:2030
0x63eeed build_sym
../../gcc/fortran/decl.c:1685
0x649969 variable_decl
../../gcc/fortran/decl.c:2793
0x649969 gfc_match_data_decl()
../../gcc/fortran/decl.c:6195
0x6ad323 match_word
../../gcc/fortran/parse.c:65
0x6ad323 decode_statement
../../gcc/fortran/parse.c:376
0x6aed6a next_free
../../gcc/fortran/parse.c:1280
0x6aed6a next_statement
../../gcc/fortran/parse.c:1512
0x6b03bb parse_spec
../../gcc/fortran/parse.c:3923
0x6b4e30 parse_block_data
../../gcc/fortran/parse.c:6026
0x6b4e30 gfc_parse_file()
../../gcc/fortran/parse.c:6413
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug c++/95820] [10/11 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820

Marek Polacek  changed:

   What|Removed |Added

Summary|ICE in  |[10/11 Regression] ICE in
   |splice_late_return_type, at |splice_late_return_type, at
   |cp/pt.c:29034   |cp/pt.c:29034
   Target Milestone|--- |10.2

--- Comment #4 from Marek Polacek  ---
Started with r10-6571-ga6ee556c7659877bb59b719f11ca2153e86ded59

[Bug fortran/95879] [10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95879

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

While not embedded :


$ cat y1.f90
module m
contains
   integer function f(x) bind(c)
  use iso_c_binding
  c_funloc(f) = x
   end
end


$ cat y2.f90
module m
contains
   integer function f(x)
  use iso_c_binding
  c_funloc(f) = x
   end
end


$ gfortran-11-20200621 -c y2.f90
y2.f90:5:15:

5 |   c_funloc(f) = x
  |   1
Error: Function result 'f' at (1) is invalid as X argument to C_FUNLOC

[Bug fortran/95879] New: [10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95879

Bug ID: 95879
   Summary: [10/11 Regression] ICE in gfc_get_derived_type, at
fortran/trans-types.c:2729
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190630 and 20190728 :


$ cat z1.f90
module m
contains
   integer function f(x) bind(c)
  use iso_c_binding
   contains
  subroutine s
 c_funloc(f) = x
  end
   end
end


$ cat z2.f90
module m
contains
   integer function f(x)
  use iso_c_binding
   contains
  subroutine s
 c_funloc(f) = x
  end
   end
end


$ gfortran-10-20190630 -c z1.f90
$
$ gfortran-11-20200621 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbce57f crash_signal
../../gcc/toplev.c:328
0x6d07a5 gfc_resolve_formal_arglist(gfc_symbol*)
../../gcc/fortran/resolve.c:313
0x6ebde2 do_traverse_symtree
../../gcc/fortran/symbol.c:4162
0x6d0fc3 resolve_formal_arglists
../../gcc/fortran/resolve.c:563
0x6d0fc3 resolve_contained_functions
../../gcc/fortran/resolve.c:1129
0x6d0fc3 resolve_types
../../gcc/fortran/resolve.c:17164
0x6d11a0 resolve_types
../../gcc/fortran/resolve.c:17186
0x6d11a0 resolve_types
../../gcc/fortran/resolve.c:17186
0x6cc7ac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17290
0x6b46f2 gfc_parse_file()
../../gcc/fortran/parse.c:6448
0x70098f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug c++/95878] ICE when compiling code that mixes an empty class, [[no_unique_address]] and non-trivial default and copy constructors

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95878

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Marek Polacek  ---
(In reply to Boris Staletic from comment #0)
> Hello,
> 
> first, apologies for a bad title. I was unsure how to make it more
> descriptive.

No worries, thanks for the bug report.

It's actually a dup, but the additional testcase might be useful.

*** This bug has been marked as a duplicate of bug 93711 ***

[Bug c++/93711] [9/10/11 Regression] ICE: [[no_unique_address] when constructing via template helper

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711

--- Comment #6 from Marek Polacek  ---
Another test:

struct istream_iterator {
istream_iterator() {}
istream_iterator(const istream_iterator&) {}
};

istream_iterator next(istream_iterator&& bound) {
return static_cast(bound);
}

struct copy_result {
[[no_unique_address]] istream_iterator in;
};

int main() {
copy_result result{next(istream_iterator{})};
}

[Bug c++/93711] [9/10/11 Regression] ICE: [[no_unique_address] when constructing via template helper

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711

Marek Polacek  changed:

   What|Removed |Added

 CC||boris.staletic at gmail dot com

--- Comment #5 from Marek Polacek  ---
*** Bug 95878 has been marked as a duplicate of this bug. ***

[Bug fortran/95877] [9 regression] ICE in test case gfortran.dg/pr95689.f90 after r9-8693

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95877

--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #0)
> g:84323d9fa7526496d844f167f6353e0ec12279e8, r9-8693 
> 
> This same error occurs on both gcc 8 and 9.  Bad backport maybe?

I do not get this error on x86_64-pc-linux-gnu, but we've seen this
before.

The backport was for a sort of borderline technical regression.
The fix is most likely contained in related patches that did not
backport straighforwardly.

I'd rather revert the commit on 8/9.

[Bug c++/95878] New: ICE when compiling code that mixes an empty class, [[no_unique_address]] and non-trivial default and copy constructors

[boris.staletic at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95878

Bug ID: 95878
   Summary: ICE when compiling code that mixes an empty class,
[[no_unique_address]] and non-trivial default and copy
constructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris.staletic at gmail dot com
  Target Milestone: ---

Hello,

first, apologies for a bad title. I was unsure how to make it more descriptive.

My repro case looks suspiciously like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432

However, the bug in 90432 has been fixed in 10.1 and 9.3. I've encountered a
similar code that still triggers an ICE. Just like 90432, gcc 8 works fine.
I've encountered a non-minimal version of this bug while working on the
nanorange library.

The minimal code that causes ICE:

struct istream_iterator {
istream_iterator() {}
istream_iterator(const istream_iterator&) {}
};

istream_iterator next(istream_iterator&& bound) {
return static_cast(bound);
}

struct copy_result {
[[no_unique_address]] istream_iterator in;
};

int main() {
copy_result result{next(istream_iterator{})};
}


during RTL pass: expand
: In function 'int main()':
:15:45: internal compiler error: in assign_temp, at function.c:982
   15 |  copy_result result{next(istream_iterator{})};
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler returned: 1

[Bug rtl-optimization/89310] Poor code generation returning float field from a struct

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310

--- Comment #4 from Segher Boessenkool  ---
Maybe you can make a define_insn_and_split for the lshrdi3 plus this?
Which will split to an insn fewer immediately.

If you split after reload you need many extra patterns to get the most
basic optimisations done for its result...  But (at least in this case)
you do not need a peephole at least ;-)

[Bug c++/95870] [8/9/10/11 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
   Keywords||ice-on-valid-code
Summary|ICE(segmentation fault) in  |[8/9/10/11 Regression] ICE
   |most_general_template(), in |(segmentation fault) in
   |gcc/cp/pt.c |most_general_template(), in
   ||gcc/cp/pt.c

--- Comment #4 from Marek Polacek  ---
Valid code that ICEs:

template  struct S {
  S();
  int b = []() -> int { enum E {}; return 1; }();
};
struct C : S {
  C();
};
template  S::S() = default;
C::C() {}

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67311

--- Comment #7 from Tobias Burnus  ---
Patch – without one recursively checks the same type.

--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -330,6 +330,11 @@ gfc_has_alloc_comps (tree type, tree decl)
return false;
 }

+  if (GFC_DESCRIPTOR_TYPE_P (type)
+  && (GFC_TYPE_ARRAY_AKIND (type) == GFC_ARRAY_POINTER
+ || GFC_TYPE_ARRAY_AKIND (type) == GFC_ARRAY_POINTER_CONT))
+return false;
+
   if (GFC_DESCRIPTOR_TYPE_P (type) || GFC_ARRAY_TYPE_P (type))
 type = gfc_get_element_type (type);

[Bug tree-optimization/95866] vectorized shift with scalar argument not correctly costed

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95866

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:c78907d514d65483c7ddfb4cb1f5c57f23da73d9

commit r11-1633-gc78907d514d65483c7ddfb4cb1f5c57f23da73d9
Author: Richard Biener 
Date:   Wed Jun 24 15:49:00 2020 +0200

tree-optimization/95866 - avoid vectorizing uniform SLP subgraphs

This avoids vectorizing SLP subgraphs that just compute uniform
operations on all-same operands.  That fixes the less interesting
(but most embarrasing) part of the testcase in the PR.  On the
way it also fixed a missing matches[0] reset in the last
refactoring touching that place.

2020-06-24  Richard Biener  

PR tree-optimization/95866
* tree-vect-slp.c (vect_slp_tree_uniform_p): New.
(vect_build_slp_tree_2): Properly reset matches[0],
ignore uniform constants.

* gcc.target/i386/pr95866-1.c: New testcase.

[Bug fortran/95877] New: gfortran.dg/pr95689.f90

[seurer at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95877

Bug ID: 95877
   Summary: gfortran.dg/pr95689.f90
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:84323d9fa7526496d844f167f6353e0ec12279e8, r9-8693 

This same error occurs on both gcc 8 and 9.  Bad backport maybe?

commit 84323d9fa7526496d844f167f6353e0ec12279e8
Author: Harald Anlauf 
Date:   Sat Jun 20 16:09:45 2020 +0200

PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015

With submodules, name mangling of interfaces may result in long internal
symbols overflowing an internal buffer.  We now check that we do not
exceed the enlarged buffer size.

gcc/fortran/
PR fortran/95689
* interface.c (check_sym_interfaces): Enlarge temporary buffer,
and add check on length on mangled name to prevent overflow.

(cherry picked from commit 62c0c0ea7bfb6f8f6b8d767b05120cafb6823da6)


Executing on host:
/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-9-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-9-test/gcc/testsuite/gfortran.dg/pr95689.f90   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never-O  -fsecond-underscore -S -o pr95689.s   
(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-9-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-9-test/gcc/testsuite/gfortran.dg/pr95689.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -fsecond-underscore -S -o pr95689.s
f951: internal compiler error: Segmentation fault
0x1090cd5b crash_signal
/home/seurer/gcc/git/gcc-9-test/gcc/toplev.c:326
gfortran: internal compiler error: Segmentation fault signal terminated program
f951

Unfortunately the traceback in gdb isn't much help:

Program received signal SIGSEGV, Segmentation fault.
0x3930313233343534 in ?? ()
(gdb) where
#0  0x3930313233343534 in ?? ()
#1  0x3930313233343536 in ?? ()
Cannot access memory at address 0x3334353637383940

[Bug c++/95870] ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870

--- Comment #3 from Marek Polacek  ---
Reduced, but invalid:

template  class a {
public:
  a();
  int b = [] { enum E {}; };
};
class c : a {
  c();
};
template  a::a() = default;
c::c() {}

[Bug c++/95870] ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870

--- Comment #2 from Marek Polacek  ---
Looks like it started with r251433.

[Bug c++/95820] ICE in splice_late_return_type, at cp/pt.c:29034

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820

--- Comment #3 from Marek Polacek  ---
Hit this when reducing something:

template class a b[]()->int

So it'd be nice to fix it to alleviate problems when reducing C++ code.

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #10 from Tamar Christina  ---
Hi Vlad,

Just curious if you had a chance to think about an approach to this that would
be acceptable.

[Bug tree-optimization/95853] Failure to optimize add overflow pattern to __builtin_add_overflow

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95853

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/95870] ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed, don't see any existing PRs for this.

Going to bisect + reduce.

[Bug c++/95870] ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-24
 Ever confirmed|0   |1

[Bug c++/88752] [8 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13328

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88752

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||mpolacek at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED

--- Comment #13 from Marek Polacek  ---
Even GCC 8 was fixed, closing.

[Bug c++/78906] ICE with a member variable template whose type is a decltype of a member variable template of a class template

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78906

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
GCC >= 7 fixed, closing.

[Bug go/95876] New: Error in compiling gcc-11-20200621 with gcc-10 without -g

[570070308 at qq dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95876

Bug ID: 95876
   Summary: Error in compiling gcc-11-20200621 with gcc-10 without
-g
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: 570070308 at qq dot com
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 48781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48781&action=edit
fullscreenlog and a sh file

This is my host gcc version:
ig@ig-vmware71:~$ gcc-10 -v
Using built-in specs.
COLLECT_GCC=gcc-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10.1.0-3ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-JWjDxk/gcc-10-10.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-JWjDxk/gcc-10-10.1.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (Ubuntu 10.1.0-3ubuntu1)

The status:
Successfully building gcc-11-20200614 with gcc-10 by default.
Successfully building gcc-11-20200614 with gcc-10 without -g.
Successfully building gcc-11-20200621 with gcc-10 by default.
Failed building gcc-11-20200621 with gcc-10 without -g.


Part of the error log:
mv -f .deps/matmul_c8.Tpo .deps/matmul_c8.Plo
f="context.o"; if test ! -f $f; then f="./.libs/context.o"; fi;
x86_64-linux-gnu-objcopy -j .go_export $f context.s-gox.tmp; /bin/bash
../../../../gcc-11-20200621/libgo/mvifdiff.sh context.s-gox.tmp `echo
context.s-gox | sed -e 's/s-gox/gox/'`
echo timestamp > context.s-gox
f="crypto/cipher.o"; if test ! -f $f; then f="crypto/.libs/cipher.o"; fi;
x86_64-linux-gnu-objcopy -j .go_export $f crypto/cipher.s-gox.tmp; /bin/bash
../../../../gcc-11-20200621/libgo/mvifdiff.sh crypto/cipher.s-gox.tmp `echo
crypto/cipher.s-gox | sed -e 's/s-gox/gox/'`
echo timestamp > crypto/cipher.s-gox
f="crypto/sha512.o"; if test ! -f $f; then f="crypto/.libs/sha512.o"; fi;
x86_64-linux-gnu-objcopy -j .go_export $f crypto/sha512.s-gox.tmp; /bin/bash
../../../../gcc-11-20200621/libgo/mvifdiff.sh crypto/sha512.s-gox.tmp `echo
crypto/sha512.s-gox | sed -e 's/s-gox/gox/'`
during GIMPLE pass: vrp
[01m[K../../../gcc-11-20200621/libgo/go/golang.org/x/crypto/ed25519/internal/edwards25519/edwards25519.go:[m[K
In function ‘[01m[Kedwards25519.GeDoubleScalarMultVartime[m[K’:
[01m[K../../../gcc-11-20200621/libgo/go/golang.org/x/crypto/ed25519/internal/edwards25519/edwards25519.go:879:1:[m[K
[01;31m[Kinternal compiler error: [m[KSegmentation fault
  879 | func GeDoubleScalarMultVartime(r *ProjectiveGroupElement, a *[32]byte,
A *ExtendedGroupElement, b *[32]byte) {
  | [01;31m[K^[m[K
echo timestamp > crypto/sha512.s-gox
f="crypto/ed25519/internal/edwards25519.o"; if test ! -f $f; then
f="crypto/ed25519/internal/.libs/edwards25519.o"; fi; x86_64-linux-gnu-objcopy
-j .go_export $f crypto/ed25519/internal/edwards25519.s-gox.tmp; /bin/bash
../../../../gcc-11-20200621/libgo/mvifdiff.sh
crypto/ed25519/internal/edwards25519.s-gox.tmp `echo
crypto/ed25519/internal/edwards25519.s-gox | sed -e 's/s-gox/gox/'`
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [Makefile:2870:
golang.org/x/crypto/ed25519/internal/edwards25519.lo] Error 1
make[4]: *** Waiting for unfinished jobs

The log is generated by `script ../screen.log`. It seems that the colorful
warning generated by compiler turn to Garbage characters. But the log is too
long so I can't copy the log from the shell. I will upload the full log file. I
will upload the full log file with an attached archive (rar) because the log
file is 31.2Mb, and it is too large to upload. Sorry.

All the build is in the same environment, and the same configure:
../gcc-11-20200621(gcc-11-202

[Bug libstdc++/95851] [10/11 Regression] std::to_chars(p, p, c, 2) segfault

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95851

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Fixed for 10.2

[Bug c++/95875] New: Misleading error message "invalid use of incomplete type"

[haoxintu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95875

Bug ID: 95875
   Summary: Misleading error message "invalid use of incomplete
type"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

$cat bug.cc
class A: 
public 
A,
A,
A
{} g_class;

$g++ -c bug.cc
bug.cc:5:1: error: invalid use of incomplete type ‘class A’
5 | A
  | ^
bug.cc:1:7: note: forward declaration of ‘class A’
1 | class A:
  |   ^
bug.cc:5:1: error: invalid use of incomplete type ‘class A’
5 | A
  | ^
bug.cc:1:7: note: forward declaration of ‘class A’
1 | class A:
  |   ^
bug.cc:5:1: error: invalid use of incomplete type ‘class A’
5 | A
  | ^
bug.cc:1:7: note: forward declaration of ‘class A’
1 | class A:
  |   ^

While in clang
$clang++ -c bug.cc
bug.cc:3:1: error: base class has incomplete type
A,
^
bug.cc:1:7: note: definition of 'A' is not complete until the closing '}'
class A: 
  ^
1 error generated.

I doubt that how GCC deals with this case. I guess there might be two
situations:
1. GCC gives the wrong line number.
2. GCC just emits the duplicated messages.

I guess GCC might have the second issue. I have tested in almost all GCC
versions, and they all have this issue.

[Bug target/95874] New: CLWB isn't supported on Icelake client

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95874

Bug ID: 95874
   Summary: CLWB isn't supported on Icelake client
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

CLWB isn't supported on Ice Lake client.  Only Tiger Lake supports it.

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95839

--- Comment #4 from Richard Biener  ---
OK, with some pending patch applied and 

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index ca6bedc9cc8..3d5de39383c 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3130,7 +3130,7 @@ vect_slp_analyze_bb_1 (bb_vec_info bb_vinfo, int n_stmts,
bool &fatal)
   return false;
 }

-  if (BB_VINFO_DATAREFS (bb_vinfo).length () < 2)
+  if (0 && BB_VINFO_DATAREFS (bb_vinfo).length () < 2)
 {
   if (dump_enabled_p ())
 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,

this only fails to vectorize due to cost considerations (considering to
code-generate as I wrote):

0x53b15a0 _1 + _2 1 times vector_stmt costs 12 in body
0x53b15a0  1 times vec_construct costs 8 in prologue
0x53b15a0  1 times vec_construct costs 8 in prologue
0x5412d10 _1 + _2 1 times scalar_stmt costs 12 in body
0x5412d10 _4 + _5 1 times scalar_stmt costs 12 in body

but with -fno-vect-cost-model it "works" as I guessed.  For division
we correctly do not vectorize.

[Bug c++/95873] New: Duplicated warning message "'class' tag used in naming 'union a'"

[haoxintu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95873

Bug ID: 95873
   Summary: Duplicated warning message "'class' tag used in naming
'union a'"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This code, bug.cc, GCC emits two duplicated warning messages.

$cat bug.cc
union a{};
auto var = new (typename :: a );

$g++ -c -fpermissive bug.cc
bug.cc:2:29: warning: 'class' tag used in naming 'union a' [-fpermissive]
2 | auto var = new (typename :: a );
  | ^
bug.cc:1:7: note: 'union a' was previously declared here
1 | union a{};
  |   ^
bug.cc:2:29: warning: 'class' tag used in naming 'union a' [-fpermissive]
2 | auto var = new (typename :: a );
  | ^
bug.cc:1:7: note: 'union a' was previously declared here
1 | union a{};
  |   ^

All GCC-6 to GCC-trunk versions have this issue.

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95839

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #1)
> GCC does not yet vectorize stmts without loads (and explicitely rejects
> vector types somewhere).

But this particular case might be easy since we already vectorize from CTORs,
we likely just disregard the BB because it doesn't contain any datarefs:

  _1 = BIT_FIELD_REF ;
  _2 = BIT_FIELD_REF ;
  _3 = _1 + _2;
  _4 = BIT_FIELD_REF ;
  _5 = BIT_FIELD_REF ;
  _6 = _4 + _5;
  _9 = {_3, _6};

vectorization might turn this into

 _10 = {_1, _4 };
 _11 = {_2, _5 };
 _9 = _10 + _11;

and then forwprop CTOR "folding" will get rid of the
_10 and _11 CTORs (until the vectorizer handles BIT_FIELD_REFs
of existing vectors).

So kind-of "easy hack" - Martin, your branch might already do this
(not give up on <= 1 datarefs).

[Bug c++/95872] New: Duplicated warning message in "-Wlogical-op"

[haoxintu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95872

Bug ID: 95872
   Summary: Duplicated warning message in "-Wlogical-op"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This code, bug.cc, GCC emits two duplicated warning messages about it.

$cat bug.cc
int a = 10;
decltype(( a or a ) ? 1:0) var = 0;


$g++ -c -Wlogical-op bug.cc
bug.cc:2:14: warning: logical 'or' of equal expressions [-Wlogical-op]

2 | decltype(( a or a ) ? 1:0) var = 0;

  |~~^~~~

bug.cc:2:14: warning: logical 'or' of equal expressions [-Wlogical-op]

All GCC-6 to GCC-trunk versions have this issue.

[Bug c++/95871] New: Duplicated error message : "the value is not usable in a constant expression"

[haoxintu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95871

Bug ID: 95871
   Summary: Duplicated error message : "the value is not usable in
a constant expression"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This code, bug.cc, GCC emits two duplicated error messages in "the value of ‘a’
is not usable in a constant expression".

$cat bug.cc
long a = 10;
enum E { emator_1 = a } enum_var;

$g++ -c bug.cc
bug.cc:2:21: error: the value of ‘a’ is not usable in a constant expression
2 | enum E { emator_1 = a } enum_var;
  | ^
bug.cc:1:6: note: ‘long int a’ is not const
1 | long a = 10;
  |  ^
bug.cc:2:21: error: the value of ‘a’ is not usable in a constant expression
2 | enum E { emator_1 = a } enum_var;
  | ^
bug.cc:1:6: note: ‘long int a’ is not const
1 | long a = 10;
  |  ^
bug.cc:2:21: error: enumerator value for ‘emator_1’ is not an integer constant
2 | enum E { emator_1 = a } enum_var;
  |   

While in clang
$clang++ -c bug.cc
bug.cc:2:21: error: expression is not an integral constant expression
enum E { emator_1 = a } enum_var;
^
bug.cc:2:21: note: read of non-const variable 'a' is not allowed in a constant
expression
bug.cc:1:6: note: declared here
long a = 10;
 ^
1 error generated.

I have tested in almost all GCC versions, they all have this issue.

[Bug c++/95870] New: ICE(segmentation fault) in most_general_template(), in gcc/cp/pt.c

[viktor.rosendahl at bmw dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870

Bug ID: 95870
   Summary: ICE(segmentation fault) in most_general_template(), in
gcc/cp/pt.c
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: viktor.rosendahl at bmw dot de
  Target Milestone: ---

Created attachment 48780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48780&action=edit
Selfcontained example (preprocessed cource code)

I can reproduce this bug with the following gcc versions:
9.3.0
10.1.0
11.0.0 20200624 (experimental) [this was built with revision eb0ff770e29 from
git://gcc.gnu.org/git/gcc.git, which was the tip of the master branch on 24th
of June, 2020]

The bug does not happen with:
7.5.0

I have not tested any 8.x version.

All compilers were built from pristine sources, no patches added.

My system is a x86_64 machine with Ubuntu 18.04.4 LTS.

I configured all compiler builds like this:
./configure --disable-multilib --prefix=/home/viktor/gcc-bin-9.3.0
--enable-languages=c,c++

Steps to reproduce:
xz -dc preproc_example4.ii.xz > preproc_example4.ii
g++  -c -pipe -O2 -Wall -std=c++17 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG
-DQT_GUI_LIB -DQT_CORE_LIB  -o obj/example4.o preproc_example4.ii

I get the following output (with gcc-9.3.0):
example4.cpp: In instantiation of ‘BungleFooBar::BungleFooBar() [with U =
FailFoo; V = BotchFoo]’:
example4.cpp:44:22:   required from here
example4.cpp:17:5: internal compiler error: Segmentation fault
   17 | MACRO_FOOBAR(foofoobar, bar);
  | ^
0xb8ff1f crash_signal
../.././gcc/toplev.c:326
0x6e4260 most_general_template(tree_node*)
../.././gcc/cp/pt.c:23652
0x6e457d enclosing_instantiation_of
../.././gcc/cp/pt.c:13424
0x701c53 tsubst_function_decl
../.././gcc/cp/pt.c:12943
0x6fe2b8 tsubst_decl
../.././gcc/cp/pt.c:13464
0x6f9ee7 tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:14365
0x70263a lookup_template_class_1
../.././gcc/cp/pt.c:9483
0x70263a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../.././gcc/cp/pt.c:9771
0x700e5d tsubst_aggr_type
../.././gcc/cp/pt.c:12764
0x6f9cbf tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:14447
0x6fe940 tsubst_decl
../.././gcc/cp/pt.c:13731
0x6f9ee7 tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:14365
0x6f42ce tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17173
0x6f2378 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17088
0x6f24ec tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17389
0x6f24ec tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17389
0x6f5885 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../.././gcc/cp/pt.c:17073
0x6f5885 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:18301
0x6f7775 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:19666
0x6f618e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:18918
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug fortran/95869] New: ICE when "target parallel" construct used with "if" clause in Fortran

[kcy at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95869

Bug ID: 95869
   Summary: ICE when "target parallel" construct used with "if"
clause in Fortran
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kcy at codesourcery dot com
  Target Milestone: ---

Compiling the following program results in an ICE:

program target_parallel_if
  implicit none

  integer, parameter :: N = 100
  integer, parameter :: LIMIT = 60
  integer :: i, j
  integer, dimension(N) :: a = (/ (i, i = 1,N) /)
  do j = 1, N
!$omp target parallel if(j .lt. LIMIT) map(tofrom: a(1:N))
do i = 1, N
  a(i) = a(i) + 1
end do
!$omp end target parallel
end do
end program

$ x86_64-none-linux-gnu-gfortran target_parallel_if.f90 -O -fopenmp -S -o
target_parallel_if.s 
target_parallel_if.f90:9:0:

9 | !$omp target parallel if(j .lt. LIMIT) map(tofrom: a(1:N))
  | 
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2830
0xf6c765 gimplify_var_or_parm_decl
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:2830
0xf9efdc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:14071
0xf76084 gimplify_modify_expr
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:5782
0xf9d09b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:13612
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf696fc gimplify_statement_list
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1869
0xf9ef01 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:14055
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf67d53 gimplify_bind_expr
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1424
0xf9ddfc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:13812
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf696fc gimplify_statement_list
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1869
0xf9ef01 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:14055
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf67d53 gimplify_bind_expr
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1424
0xf9ddfc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:13812
0xf7a44b gimplify_stmt(tree_node**, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:6825
0xf65136 gimplify_and_add(tree_node*, gimple**)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:486
0xf6960a gimplify_loop_expr
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:1843
0xf9de1d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/gimplify.c:13816
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The issue seems to have been present since GCC 8. In GCC 7, it also ICEs but
with a different backtrace:

$ x86_64-none-linux-gnu-gfortran target_parallel_if.f90 -O -fopenmp -S -o
target_parallel_if.s
f951: internal compiler error: in parse_omp_structured_block, at
fortran/parse.c:5096
0x89fec2 parse_omp_structured_block 
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/fortran/parse.c:5096 
0x8a02f5 parse_executable   
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/fortran/parse.c:5345 
0x89f541 parse_do_block 
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/fortran/parse.c:4649 
0x8a0280 parse_executable   
/scratch/kyeung/openacc/trunk/src/gcc-mainline/gcc/fortran/parse.c:5299 
0x8a0c04 par

[Bug target/95660] get_intel_cpu in cpuinfo.c contains unnecessary check for brand_id

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95660

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/95660] get_intel_cpu in cpuinfo.c contains unnecessary check for brand_id

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95660

--- Comment #2 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:134f7c941929b3d099322a89928c04e5ac69267e

commit r11-1631-g134f7c941929b3d099322a89928c04e5ac69267e
Author: H.J. Lu 
Date:   Fri Jun 12 16:33:23 2020 -0700

x86: Remove brand ID check for Intel processors

Brand ID was a feature that briefly existed in some Pentium III and
Pentium 4 CPUs.  The CPUs that had non-zero brand ID still have had
valid family/model.  Brand ID just gives a marketing name for the CPU.
Remove the extra code for brand ID check.

gcc/

PR target/95660
* common/config/i386/cpuinfo.h (get_intel_cpu): Remove brand_id.
(cpu_indicator_init): Likewise.
* config/i386/driver-i386.c (host_detect_local_cpu): Updated.

gcc/testsuite/

PR target/95660
* gcc.target/i386/builtin_target.c (check_detailed): Updated.

[Bug target/95774] __builtin_cpu_is can't detect cooperlake

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95774

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/95843] Duplicated ISA info in driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95843

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |11.0

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 11.

[Bug ipa/95859] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

[tobi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859

--- Comment #3 from Tobias Schlüter  ---
ps here's the compiler explorer link for the preprocessed test. 
https://godbolt.org/z/zDw5JQ

I tried manually reducing it, but couldn't easily get below the 1000kib limit.

[Bug libstdc++/95851] [10/11 Regression] std::to_chars(p, p, c, 2) segfault

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95851

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:ff5c8fe44a98025c1e700cfc033247965e293869

commit r10-8360-gff5c8fe44a98025c1e700cfc033247965e293869
Author: Jonathan Wakely 
Date:   Tue Jun 23 22:47:58 2020 +0100

libstdc++: Fix std::to_chars buffer overflow (PR 95851)

The __detail::__to_chars_2 function assumes it won't be called with zero
values. However, when the output buffer is empty the caller doesn't
handle zero values correctly, and calls __to_chars_2 with a zero value,
resulting in an overflow of the empty buffer.

The __detail::__to_chars_i function should just return immediately for
an empty buffer, and otherwise ensure zero values are handled properly.

libstdc++-v3/ChangeLog:

PR libstdc++/95851
* include/std/charconv (__to_chars_i): Check for zero-sized
buffer unconditionally.
* testsuite/20_util/to_chars/95851.cc: New test.

(cherry picked from commit be50843754b4c4d47f0d628a84b3dbf2a4145a43)

[Bug target/95774] __builtin_cpu_is can't detect cooperlake

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95774

--- Comment #2 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:403e166b974f53982d78efdd70938d05b6983b2a

commit r11-1630-g403e166b974f53982d78efdd70938d05b6983b2a
Author: H.J. Lu 
Date:   Fri Jun 19 21:17:26 2020 -0700

x86: Add Cooper Lake detection with AVX512BF16

All Sky Lake family processors have the same CPUID model number, 0x55.
The differences are Cascade Lake has AVX512VNNI and Cooper Lake has
AVX512VNNI + AVX512BF16.  Check AVX512BF16 for Cooper Lake.

PR target/95774
* common/config/i386/cpuinfo.h (get_intel_cpu): Add Cooper Lake
detection with AVX512BF16.

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95839

--- Comment #2 from Uroš Bizjak  ---
What I find interesting is a similar case with the division instead of the
addition. Clang compiles it to:

divps   %xmm1, %xmm0
retq

Considering that we have [a0, a1, 0, 0] / [b0, b1, 0, 0], this will surely fire
invalid operation exception. I have explicitly avoided generation of division
using 4-element DIVPS for v2sf operands exactly due to this issue.

[Bug target/95843] Duplicated ISA info in driver-i386.c and i386-builtins.c

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95843

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:6c35d16a3925958b3a22426de0cb8e04f654b6dd

commit r11-1629-g6c35d16a3925958b3a22426de0cb8e04f654b6dd
Author: H.J. Lu 
Date:   Wed Jun 24 04:39:16 2020 -0700

x86: Share _isa_names_table and use cpuinfo.h

Both driver-i386.c and libgcc use CPUID to detect the processor name
as well as available ISAs.  To detect the same processor or ISAs, the
same detection logic is duplicated in 2 places.  Sometimes only one place
was up to date or got it right.  Sometimes both places got it wrong.

1. Add common/config/i386/i386-isas.h to define _isa_names_table.
2. Use isa_names_table to auto-generate ISA command-line options.
3. Use isa_names_table to auto-generate __builtin_cpu_supports tests.
4. Use common/config/i386/cpuinfo.h to check available ISAs and detect
newer Intel processors in driver-i386.c and builtin_target.c.
5. Detection of AMD processors and older processors in driver-i386.c is
unchanged.

gcc/

PR target/95843
* common/config/i386/i386-isas.h: New file.  Extracted from
gcc/config/i386/i386-builtins.c.
(_isa_names_table): Add option.
(ISA_NAMES_TABLE_START): New.
(ISA_NAMES_TABLE_END): Likewise.
(ISA_NAMES_TABLE_ENTRY): Likewise.
(isa_names_table): Defined with ISA_NAMES_TABLE_START,
ISA_NAMES_TABLE_END and ISA_NAMES_TABLE_ENTRY.  Add more ISAs
from enum processor_features.
* config/i386/driver-i386.c: Include
"common/config/i386/cpuinfo.h" and
"common/config/i386/i386-isas.h".
(has_feature): New macro.
(host_detect_local_cpu): Call cpu_indicator_init to get CPU
features.  Use has_feature to detect processor features.  Call
Call get_intel_cpu to get the newer Intel CPU name.  Use
isa_names_table to generate command-line options.
* config/i386/i386-builtins.c: Include
"common/config/i386/i386-isas.h".
(_arch_names_table): Removed.
(isa_names_table): Likewise.

gcc/testsuite/

PR target/95843
* gcc.target/i386/builtin_target.c: Include ,
../../../common/config/i386/i386-cpuinfo.h and
../../../common/config/i386/cpuinfo.h.
(check_amd_cpu_model): Removed.
(check_intel_cpu_model): Likewise,
(CHECK___builtin_cpu_is): New.
(gcc_assert): New.  Defined as assert.
(gcc_unreachable): New.  Defined as abort.
(inline): New.  Defined as empty.
(ISA_NAMES_TABLE_START): Likewise.
(ISA_NAMES_TABLE_END): Likewise.
(ISA_NAMES_TABLE_ENTRY): New.
(check_features): Include
"../../../common/config/i386/i386-isas.h".
(check_detailed): Call cpu_indicator_init.  Always call
check_features.  Call get_amd_cpu instead of check_amd_cpu_model.
Call get_intel_cpu instead of check_intel_cpu_model.

[Bug ipa/95859] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

[tobi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859

--- Comment #2 from Tobias Schlüter  ---
Created attachment 48779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48779&action=edit
Preprocessed source x86 (32bit)

Here's preprocessed source for x86 (32 bit).  This shows the same behavior as
verified with the compiler explorer.

[Bug target/95864] [11 Regression] GCN offloading execution regressions after commit f062c3f11505b70c5275e5bc0e52f3e441f8afbc "amdgcn: Switch to HSACO v3 binary format"

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95864

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95867

--- Comment #3 from Richard Biener  ---
It's done through POWI internally, I guess we could open the internal function
to also operate on integers...

As for overflow for a multiplication chain of the same operand there shouldn't
be any issue, but not sure how far we should go with signed arithmetic support
early (for the late reassoc the idea is still to set flag_wrapv = 1).

We could carefully handle some cases by ensuring to only perform
"safe" linearization and for the resulting chains adjust operand sorting
to only perform "safe" commutations (basically not sort, only optimize
trailing constants / cancellations).

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95867

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-24
   Keywords||missed-optimization

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95867

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Not really __uint128_t related.  Since PR18589 we perform such optimizations on
floating point multiply, and on signed integers we punt on reassociation
because of the undefined signed overflow issues (the proposal to do a very late
reassoc that would essentially turn on -fwrapv from that point onwards or at
least turn rewritten expressions into unsigned ones has not materialized yet),
but for unsigned integral types we could indeed replace those with the minimal
number of multiplications.
Or alternatively we could do that in forwprop1, which can handle similar case
for addition into multiplications, though I guess only reassoc will be able to
handle it if it isn't just one variable as the multiplication operands, but
several.
return x * x * y * z * x * z * x * w * w * u * x * z * y * w * u * x * x * w *
w * w;
etc.

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720

--- Comment #4 from Andrea Corallo  ---
"aoliva at gcc dot gnu.org"  writes:

> --- Comment #3 from Alexandre Oliva  ---
> akrl, any clue as to where this .out is coming from in your runs?  I get .exe
> in my arm test runs; I don't see anything that selects .out, only .exe; and 
> the
> driver disregards the .exe suffix in executable output, regardless of 
> platform,
> when recognizing that the single source has the same basename as the linker
> output.

Hi Alexandre,

Apologies I guess the provided example was not the best.

Here what I've specifically for the mentioned testcase, this is the
compiler invocation:

.../build/gcc/xgcc -B.../build/gcc/
.../src/gcc/gcc/testsuite/gcc.target/arm/memset-inline-1.c gcc_tg.o
-march=armv8.1-m.main -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -save-temps -O2 -fno-inline -ffat-lto-objects
-fno-ident -specs=rdimon.specs -Wa,-mno-warn-deprecated
-Wl,-Ttext-segment=0x0050 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main
-Wl,-wrap,abort -lm -o ./memset-inline-1.exe

The assembly file generated is called
'memset-inline-1-memset-inline-1.s' but IIUC the expected one by proc
'scan-assembler-not' (scanasm.exp:92) is 'memset-inline-1.s' (I'm just
printing $output_file).

Hope it helps.

  Andrea

[Bug target/95259] Duplicated codes in libgcc, driver-i386.c and i386-builtins.c

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95259

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/95864] [11 Regression] GCN offloading execution regressions after commit f062c3f11505b70c5275e5bc0e52f3e441f8afbc "amdgcn: Switch to HSACO v3 binary format"

[ams at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95864

--- Comment #1 from Andrew Stubbs  ---
I'm aware of these issues.

I fixed all the test failures that were definitely bugs in the HSACOv3
implementation, and the ones that remain appear to be either latent bugs
uncovered by the new driver configuration, or possibly even not our problem.

Of course, I could be mistaken, but I won't find out until I find time to look
closer.

[Bug target/95259] Duplicated codes in libgcc, driver-i386.c and i386-builtins.c

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95259

--- Comment #4 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:1890f2f0e210ef515c39728c54151372d36dd187

commit r11-1627-g1890f2f0e210ef515c39728c54151372d36dd187
Author: H.J. Lu 
Date:   Mon May 18 05:58:41 2020 -0700

x86: Move cpuinfo.h from libgcc to common/config/i386

Both x86 backend and libgcc define enum processor_features.  libgcc sets
enum processor_feature and x86 backend checks enum processor_feature.
They are very easy out of sync and it has happened multiple times in the
past.

1. Move cpuinfo.h from libgcc to common/config/i386 so that we can share
the same enum processor_features in x86 backend and libgcc.
2. Change __cpu_features2 to an array to support more processor features.
3. Add more processor features to enum processor_features.

gcc/

PR target/95259
* common/config/i386/cpuinfo.h: New file.
(__processor_model): Moved from libgcc/config/i386/cpuinfo.h.
(__processor_model2): New.
(CHECK___builtin_cpu_is): New.  Defined as empty if not defined.
(has_cpu_feature): New function.
(set_cpu_feature): Likewise.
(get_amd_cpu): Moved from libgcc/config/i386/cpuinfo.c.  Use
CHECK___builtin_cpu_is.  Return AMD CPU name.
(get_intel_cpu): Moved from libgcc/config/i386/cpuinfo.c.  Use
Use CHECK___builtin_cpu_is.  Return Intel CPU name.
(get_available_features): Moved from libgcc/config/i386/cpuinfo.c.
Also check FEATURE_3DNOW, FEATURE_3DNOWP, FEATURE_ADX,
FEATURE_ABM, FEATURE_CLDEMOTE, FEATURE_CLFLUSHOPT, FEATURE_CLWB,
FEATURE_CLZERO, FEATURE_CMPXCHG16B, FEATURE_CMPXCHG8B,
FEATURE_ENQCMD, FEATURE_F16C, FEATURE_FSGSBASE, FEATURE_FXSAVE,
FEATURE_HLE, FEATURE_IBT, FEATURE_LAHF_LM, FEATURE_LM,
FEATURE_LWP, FEATURE_LZCNT, FEATURE_MOVBE, FEATURE_MOVDIR64B,
FEATURE_MOVDIRI, FEATURE_MWAITX, FEATURE_OSXSAVE,
FEATURE_PCONFIG, FEATURE_PKU, FEATURE_PREFETCHWT1, FEATURE_PRFCHW,
FEATURE_PTWRITE, FEATURE_RDPID, FEATURE_RDRND, FEATURE_RDSEED,
FEATURE_RTM, FEATURE_SERIALIZE, FEATURE_SGX, FEATURE_SHA,
FEATURE_SHSTK, FEATURE_TBM, FEATURE_TSXLDTRK, FEATURE_VAES,
FEATURE_WAITPKG, FEATURE_WBNOINVD, FEATURE_XSAVE, FEATURE_XSAVEC,
FEATURE_XSAVEOPT and FEATURE_XSAVES
(cpu_indicator_init): Moved from libgcc/config/i386/cpuinfo.c.
Also update cpu_model2.
* common/config/i386/i386-cpuinfo.h (processor_vendor): Add
Add VENDOR_CENTAUR, VENDOR_CYRIX and VENDOR_NSC.
(processor_features): Moved from gcc/config/i386/i386-builtins.c.
Renamed F_XXX to FEATURE_XXX.  Add FEATURE_3DNOW, FEATURE_3DNOWP,
FEATURE_ADX, FEATURE_ABM, FEATURE_CLDEMOTE, FEATURE_CLFLUSHOPT,
FEATURE_CLWB, FEATURE_CLZERO, FEATURE_CMPXCHG16B,
FEATURE_CMPXCHG8B, FEATURE_ENQCMD, FEATURE_F16C,
FEATURE_FSGSBASE, FEATURE_FXSAVE, FEATURE_HLE, FEATURE_IBT,
FEATURE_LAHF_LM, FEATURE_LM, FEATURE_LWP, FEATURE_LZCNT,
FEATURE_MOVBE, FEATURE_MOVDIR64B, FEATURE_MOVDIRI,
FEATURE_MWAITX, FEATURE_OSXSAVE, FEATURE_PCONFIG,
FEATURE_PKU, FEATURE_PREFETCHWT1, FEATURE_PRFCHW,
FEATURE_PTWRITE, FEATURE_RDPID, FEATURE_RDRND, FEATURE_RDSEED,
FEATURE_RTM, FEATURE_SERIALIZE, FEATURE_SGX, FEATURE_SHA,
FEATURE_SHSTK, FEATURE_TBM, FEATURE_TSXLDTRK, FEATURE_VAES,
FEATURE_WAITPKG, FEATURE_WBNOINVD, FEATURE_XSAVE, FEATURE_XSAVEC,
FEATURE_XSAVEOPT, FEATURE_XSAVES and CPU_FEATURE_MAX.
(SIZE_OF_CPU_FEATURES): New.
* config/i386/i386-builtins.c (processor_features): Removed.
(isa_names_table): Replace F_XXX with FEATURE_XXX.
(fold_builtin_cpu): Change __cpu_features2 to an array.

libgcc/

PR target/95259
* config/i386/cpuinfo.c: Don't include "cpuinfo.h".  Include
"common/config/i386/i386-cpuinfo.h" and
"common/config/i386/cpuinfo.h".
(__cpu_features2): Changed to array.
(get_amd_cpu): Removed.
(get_intel_cpu): Likewise.
(get_available_features): Likewise.
(__cpu_indicator_init): Call cpu_indicator_init.
* config/i386/cpuinfo.h: Removed.

[Bug fortran/95868] New: Derived-type deferred-length character component handling broken

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868

Bug ID: 95868
   Summary: Derived-type deferred-length character component
handling broken
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The following program fails with an ICE or a segfault.

Issues I observed:

* For the ICE, the issue seems to be:
  gfc_conv_loop_setup() calls
gfc_add_loop_ss_code (loop, loop->ss, false, where)
  expr = ss_info->expr;
 case GFC_SS_SCALAR:
  gfc_conv_expr (&se, expr);
  → The ICE occur because expr == NULL and expr is dereferenced.

  I am not sure whether it is the following code, but it sets
  ss-info->expr and I bet ss.end == NULL in my testcase, but I
  have not check it: 
gfc_walk_array_ref()
  if (ref->type == REF_SUBSTRING)
{
  ss = gfc_get_scalar_ss (ss, ref->u.ss.start);
  ss = gfc_get_scalar_ss (ss, ref->u.ss.end);
}
and the second argument is the 'expr'.


* For derived-type deferred strings, one often has the intcst "0" in the tree.
  for gfc_conv_expr_descriptor, for the simple case, that's handled
  (search: deferred_array_component).
  However, for the complicated case, one might end up with
"0 = 0;"
  which the gimplifier does not like.
  I am not sure whether the patch is correct, but it fixes one testcase
  for me (not shown, OpenMP one) and looks more sensible. I am not sure
  whether VAR_P(se->string_length) makes sense and when it gets set or
  defined. 

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 54e1107c711..6da8c6d5595 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -7551,15 +7551,14 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
   /* Set the string_length for a character array.  */
   if (expr->ts.type == BT_CHARACTER)
{
- se->string_length =  gfc_get_expr_charlen (expr);
- if (VAR_P (se->string_length)
- && expr->ts.u.cl->backend_decl == se->string_length)
-   tmp = ss_info->string_length;
- else
-   tmp = se->string_length;
-
- if (expr->ts.deferred)
-   gfc_add_modify (&se->pre, expr->ts.u.cl->backend_decl, tmp);
+ tmp = gfc_get_expr_charlen (expr);
+ if (!VAR_P (expr->ts.u.cl->backend_decl))
+   se->string_length = (expr->ts.deferred ? ss_info->string_length
+  : tmp);
+ else if (expr->ts.deferred
+  && se->string_length != expr->ts.u.cl->backend_decl)
+   gfc_add_modify (&se->pre, expr->ts.u.cl->backend_decl,
+   ss_info->string_length);
}

   /* If we have an array section, are assigning  or passing an array

--
implicit none
type t
  character(len=:), allocatable :: str(:)
end type t
type (t) :: var
character(len=:), allocatable :: str(:)
integer :: i

allocate(character(len=3) :: str(3))
str(:) = ["abc", "def", "ghi"]
!call dummy(str)! OK
!call dummy(str(2:))! OK
!call dummy(str(:)(2:)) ! (1) ICE

!call sub1(str) ! OK
!call sub2(str(2:)) ! (2) Segfault at runtime
!call sub3(str(:)(2:))  ! (3) ICE

var%str = ["abc", "def", "ghi"]
!call sub1(var%str)! (4) Fails at runtime ('stop 1')
!call sub2(var%str(2:))! (5) Fails at runtime ('stop 1')
!call sub3(var%str(:)(2:)) ! ICE
deallocate(str,var%str)
contains
  subroutine dummy(x)
character(len=1), dimension(*) :: x
  end
  subroutine sub1(x)
character(len=*), dimension(*) :: x
if (len(x) /= 3) stop 1
if (any (x(1:3) /= ["abc", "def", "ghi"])) stop 2
  end
  subroutine sub2(x)
character(len=*), dimension(*) :: x
if (len(x) /= 3) stop 3
if (any (x(1:2) /= ["def", "ghi"])) stop 4
  end
  subroutine sub3(x)
character(len=*), dimension(*) :: x
if (len(x) /= 2) stop 5
if (any (x(1:3) /= ["bc", "ef", "hi"])) stop 6
  end
end

[Bug tree-optimization/95867] Failure to optimize successive multiplications of ___uint128_t

[gabravier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95867

--- Comment #1 from Gabriel Ravier  ---
PS : Of course this can be optimized in the general case, I was only giving an
example here, I wouldn't want only the pattern of 653 successive
multiplications to be optimized

[Bug tree-optimization/95867] New: Failure to optimize successive multiplications of ___uint128_t

[gabravier at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95867

Bug ID: 95867
   Summary: Failure to optimize successive multiplications of
___uint128_t
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

__uint128_t f(__uint128_t n)
{
return
n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n*n;
}

This can be optimized to 

__uint128_t f2(__uint128_t n)
{
__uint128_t tmp = n * n;
tmp = (tmp * tmp) * n;
tmp *= tmp;
tmp *= tmp;
tmp *= tmp;
tmp = (tmp * tmp) * n;
tmp = (tmp * tmp) * n;
tmp *= tmp;
return (tmp * n) * tmp;
}

This transformation is done by LLVM, but not by GCC.

[Bug tree-optimization/95866] vectorized shift with scalar argument not correctly costed

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95866

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-24
 Ever confirmed|0   |1
   Keywords||missed-optimization
 Blocks||53947
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Mine.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/95866] New: vectorized shift with scalar argument not correctly costed

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95866

Bug ID: 95866
   Summary: vectorized shift with scalar argument not correctly
costed
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

int x[4];
void foo(int i)
{
  i = (i+1) & 31;
  x[0] = (x[0] << i) + i;
  x[1] = (x[1] << i) + i;
  x[2] = (x[2] << i) + i;
  x[3] = (x[3] << i) + i;
}

for this testcase we're not correctly assessing that we leave the
scalar computation for (i+1) & 31 around for the generated
vectorized shift by a scalar argument.  Since we're in need of
the vector of { i,... } for the vectorized add we ideally should
simply use lane zero for the shift operand rather than the original
SSA name as we do.  Currently:

  _22 = {i_14(D), i_14(D), i_14(D), i_14(D)};
  vect_cst__23 = _22;
  vect_cst__24 = { 1, 1, 1, 1 };
  vect__1.6_25 = vect_cst__23 + vect_cst__24;
  vect_cst__26 = { 31, 31, 31, 31 };
  vect_i_15.7_27 = vect__1.6_25 & vect_cst__26;
  _1 = i_14(D) + 1;
  i_15 = _1 & 31;
  vect__2.5_21 = MEM  [(int *)&x];
  vect__3.8_28 = vect__2.5_21 << i_15;
  vect__4.9_29 = vect__3.8_28 + vect_i_15.7_27;
  MEM  [(int *)&x] = vect__4.9_29;
  return;

where arguably we should have done the (i+1) & 31 compute with scalars
and broadcast the result.  Assembly:

foo:
.LFB0:
.cfi_startproc
leal1(%rdi), %eax
movdqa  x(%rip), %xmm1
movd%edi, %xmm3
andl$31, %eax
pshufd  $0, %xmm3, %xmm0
paddd   .LC0(%rip), %xmm0
movq%rax, %xmm2
pand.LC1(%rip), %xmm0
pslld   %xmm2, %xmm1
paddd   %xmm1, %xmm0
movaps  %xmm0, x(%rip)
ret

which is really bad.  Even with that optimization simulated by using
'i' as provided by the function argument we generate

foo:
.LFB0:
.cfi_startproc
movdqa  x(%rip), %xmm1
movslq  %edi, %rax
movd%edi, %xmm3
movq%rax, %xmm2
pshufd  $0, %xmm3, %xmm0
pslld   %xmm2, %xmm1
paddd   %xmm1, %xmm0
movaps  %xmm0, x(%rip)
ret

so RTL optimizations do not recover here either.  combine sees

(insn 8 3 9 2 (set (reg:DI 89 [ i ])
(sign_extend:DI (reg/v:SI 86 [ i ]))) "t.c":5:16 147
{*extendsidi2_rex64}
 (nil))
(insn 10 9 11 2 (set (reg:V4SI 90 [ vect__2.6 ])
(ashift:V4SI (reg:V4SI 91 [ MEM  [(int *)&x] ])
(reg:DI 89 [ i ]))) "t.c":5:16 3739 {ashlv4si3} 
 (expr_list:REG_DEAD (reg:V4SI 91 [ MEM  [(int *)&x] ])
(expr_list:REG_DEAD (reg:DI 89 [ i ])
(nil
(insn 11 10 12 2 (set (reg:V4SI 92)
(vec_duplicate:V4SI (reg/v:SI 86 [ i ]))) "t.c":5:22 5169
{*vec_dupv4si}
 (expr_list:REG_DEAD (reg/v:SI 86 [ i ])
(nil)))
(insn 12 11 13 2 (set (reg:V4SI 93 [ vect__3.7 ])
(plus:V4SI (reg:V4SI 90 [ vect__2.6 ])
(reg:V4SI 92))) "t.c":5:22 3545 {*addv4si3}

so the opportunity to "back-propagate" the vec_duplicate for the shift
isn't appearant - nor would it ever consider such thing.

So we probably should try to fix this in the vectorizer.  IIRC this support
for non-external/constant scalar shift args is reasonably new (g:49eab32e6e7).
Also if there's a vector-vector shift we should probably prefer that if
we already have a vector.

[Bug pch/64117] warning control #pragmas in precompiled headers are not obeyed for template code

[fsmoke at mail dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117

fsmoke  changed:

   What|Removed |Added

 CC||fsmoke at mail dot ru

--- Comment #4 from fsmoke  ---
Problem persists in gcc 9.3.

very very sadly