[Bug c/96284] Outdated C features should be made errors with newer standards

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||fw at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to David Brown from comment #0)
> While C has tried to remain backwards compatible with each new standards
> revision, some changes have been made so that particularly unsafe features
> from old code are no longer supported.  gcc has (reasonably enough) tried to
> keep support for old features, but when something has been deprecated for
> decades, perhaps it is time for it to be treated as an error by default and
> require an explicit flag.  (This is in the same style as bug 85678 making
> "-fno-common" the default.)
> 
> For example, implicit function declarations from K C were made obsolescent
> in C90, and removed from the language in C99.  But by default, they still
> only cause a warning (-Wimplicit-function-declaration) in gcc, no matter
> what standard is picked.
> 
> Could this be made an error by default
> (-Werror=implicit-function-declarations) ?  Let those who want to compile
> old code with implicit function declarations, do so with an explicit flag.

I think Florian Weimer tried this and it broke the majority of configure
scripts in existence...

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #19 from Richard Biener  ---
no

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

[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #13 from Richard Biener  ---
*** Bug 30604 has been marked as a duplicate of this bug. ***

[Bug libstdc++/96345] __cxa demangle fails to demangle a very long string

[hededrk at gmail dot com]

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

--- Comment #4 from V  ---
No, c++filt also does not demangle it.

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
We can force 0xfa1e0ff3 into memory with

[hjl@gnu-snb-1 tmp]$ cat bar.s
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
movl.LC0(%rip), %eax
ret
.section .rodata.cst4,"aM",@progbits,4
.align 4
.LC0:
.long  0xfa1e0ff3
.section.note.GNU-stack,"",@progbits
[hjl@gnu-snb-1 tmp]$ gcc -c bar.s
[hjl@gnu-snb-1 tmp]$ objdump -dwr bar.o

bar.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   8b 05 00 00 00 00   mov0x0(%rip),%eax# 6  
2: R_X86_64_PC32.LC0-0x4
   6:   c3  ret
[hjl@gnu-snb-1 tmp]$

[Bug lto/96343] LTO ICE on PPC64le

[luoxhu at gcc dot gnu.org]

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

--- Comment #4 from luoxhu at gcc dot gnu.org ---
I tried to build both ADIOS2 and WarpX(with INTERPROCEDURAL_OPTIMIZATION) on a
Power8 machine with gcc 9.3.0&9.2.1, no LTO error seen.

/usr/bin/cmake ../ -DCMAKE_C_COMPILER=/opt/at12.0/bin/gcc
-DCMAKE_CXX+COMPILER=/opt/at12.0/bin/g++ -DADIOS2_USE_Fortran=OFF
-DADIOS2_USE_ZeroMQ=OFF -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release
-DCMAKE_POSITION_INDEPENDENT_CODE=ON -DADIOS2_USE_SST=OFF
-DCMAKE_CXX_FLAGS="-flto -fno-fat-lto-objects ${CMAKE_CXX_FLAGS}"
 make -j50

Not sure any difference with your configuration?

Anyway, it will be much better if you could try new GCC or reduce a smaller
test case, BTW, I see that someone mentioned that it may related to conda and
python https://github.com/ornladios/ADIOS2/issues/1524#issue-458229988?

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-28
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
[hjl@gnu-snb-1 tmp]$ cat foo.c
int
foo (void)
{
  return 0xfa1e0ff3;
}
[hjl@gnu-snb-1 tmp]$ gcc -c -O2 foo.c
[hjl@gnu-snb-1 tmp]$ objdump -dw foo.o

foo.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   b8 f3 0f 1e fa  mov$0xfa1e0ff3,%eax
   5:   c3  ret
[hjl@gnu-snb-1 tmp]$ objdump -dw  --start-address=1 foo.o

foo.o: file format elf64-x86-64


Disassembly of section .text:

0001 :
   1:   f3 0f 1e fa endbr64 
   5:   c3  ret
[hjl@gnu-snb-1 tmp]$

[Bug target/96350] New: [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[crazylht at gmail dot com]

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

Bug ID: 96350
   Summary: [cet] For ENDBR immediate, the binary would include a
gadget that starts with a fake ENDBR64 opcode.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386, x86-64

ENDBR32 and ENDBR64 have specific opcodes:
-   ENDBR32: F3 0F 1E FB
-   ENDBR64: F3 0F 1E FA

And we want that attackers won’t find unintended ENDBR32/64 opcode matches in
the binary

Here’s an example:

If the compiler had to generate asm for the following code:
a = 0xF30F1EFA

it could, for example, generate:
mov 0xF30F1EFA, dword ptr[a]

In such a case, the binary would include a gadget that starts with a fake
ENDBR64 opcode.

Therefore, the requirement from the compilers is to split such generation into
multiple operations, such that the explicit immediate never shows in the binary

[Bug java/82263] java multilib -m32 version is using 64 bit include and lib, _GStaticAssertCompileTimeAssertion_0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Andrew Pinski  ---
The java front-end and libjava has been removed so closing as won't fix.

[Bug java/82263] java multilib -m32 version is using 64 bit include and lib, _GStaticAssertCompileTimeAssertion_0

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
Is this PR still relevant?

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #18 from Arseny Solokha  ---
Is this PR still relevant?

[Bug tree-optimization/96349] New: [10/11 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 3 which are marked as MUST COALESCE.) [in fail_abnormal_edge_coalesce]

[asolokha at gmx dot com]

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

Bug ID: 96349
   Summary: [10/11 Regression] ICE: SSA corruption (Unable to
coalesce ssa_names 2 and 3 which are marked as MUST
COALESCE.) [in fail_abnormal_edge_coalesce]
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200726 snapshot (g:39ddfef9a5c24acf6412236f52f6716c8e0ebc9e)
ICEs when compiling the following testcase w/ -O3:

void __attribute__ ((returns_twice))
gr (void);

void
ib (void);

void
zg (void);

void
yw (int uz)
{
  gr ();

  for (;;)
if (uz != 0)
  {
uz = 0;
ib ();
  }
else
  zg ();
}

% gcc-11.0.0 -O3 -c kl7mlgao.c

Unable to coalesce ssa_names 2 and 3 which are marked as MUST COALESCE.
uz_2(ab) and  uz_3(ab)
during RTL pass: expand
kl7mlgao.c: In function 'yw':
kl7mlgao.c:11:1: internal compiler error: SSA corruption
   11 | yw (int uz)
  | ^~
0xedadfa fail_abnormal_edge_coalesce
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/tree-ssa-coalesce.c:1003
0xedadfa coalesce_partitions
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/tree-ssa-coalesce.c:1425
0xedadfa coalesce_ssa_name(_var_map*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/tree-ssa-coalesce.c:1755
0xe78937 remove_ssa_form
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/tree-outof-ssa.c:1065
0xe78937 rewrite_out_of_ssa(ssaexpand*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/tree-outof-ssa.c:1323
0x912f80 execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200726/work/gcc-11-20200726/gcc/cfgexpand.c:6377

[Bug c/96348] The same "C" program runtime is 50 times longer on Win10 than on Linux.

[brianoh9999 at gmail dot com]

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

--- Comment #2 from Brian Oh  ---
Created attachment 48940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48940=edit
the preprocessed file (zipped)

The preprocessed file (zipped) is attached.

[Bug c/96348] The same "C" program runtime is 50 times longer on Win10 than on Linux.

[brianoh9999 at gmail dot com]

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

Brian Oh  changed:

   What|Removed |Added

 CC||brianoh at gmail dot com

--- Comment #1 from Brian Oh  ---
Created attachment 48939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48939=edit
the source file

I could not attach the preprocessed file - too large.

[Bug c/96348] New: The same "C" program runtime is 50 times longer on Win10 than on Linux.

[brianoh9999 at gmail dot com]

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

Bug ID: 96348
   Summary: The same "C" program runtime is 50 times longer on
Win10 than on Linux.
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brianoh at gmail dot com
  Target Milestone: ---

I belive that I have found what appears to be a major bug somewhere in the
compilation of an "C" program for Win10.

GCC --version shows:

gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0

The PC is an i7-8550U. The windows version is Win10 Pro, V2004-19041.388.

Compiler Command for initial run:
gcc primes.c -o primes.exe -O3
No console output from compiler.

Compiler Command for .i creation:
gcc primes.c -o primes.exe -O3 -save-temps
No console output from compiler.

This problem surfaced in a fairly simple benchmark that I wrote for various
languages including C++, Rust, Go, Dart, Java, and JS. The algorithm used is
exactly the same for all languages. The run-time on all of these languages on
Win10 ranges from 6 seconds to 15 seconds. Using GCC compiling "C", it takes
over 50 times longer than C++ (650 seconds or more vs 12.5 seconds). Assuming
it was my fault, I could see no obvious problem, so I installed WSL2 on Win10
and compiled it on Ubuntu using GCC and ran it. The result was 12.5 seconds -
the exact same code. I ran it on another Win10 i7 PC and it took 675 seconds. I
had someone (experienced in C) independently verify this, and they had the same
result both on Win10 and Linux (c. 650 seconds and 12 seconds). I compiled it
with various optimization flags including "-O", "-O3", etc. I also compiled it
using Code:Blocks (on Windows) and got the same result (runtime). The person
who verified this for me is an experienced "C" programmer.

I am an experienced programmer and have spent a lot of time researching this,
and I would therefore like to report it as a bug.

Please note. The issue is not whether the algorithm is good or bad. The issue
is that the runtime on Win10 (for 10 million) takes 50 times longer than on
Linux, and also 50 times longer than other major languages including C++.

I was unsure about your requirements as to what you do not want in regards to
the source file. You do not want:
   "A source file that #includes header files that are left out of the bug
report (see above)"
   "That source file and a collection of header files."

It was therefore unclear to me whether you want the actual source file, so I
have attached it. Well, I tried to, but it appears that you only want one
attachment.

Please note as I'm sure you will realize, this is not a question as to how good
or not the algorithm is or whether I could use the sqrt function. It is solely
about the vast discrepancy in the runtime.

I'm unsure if I selected the correct component to file this under, because the
description is "A problem with the C compiler front end". I presume it is
actually "A problem with the C compiler tool chain" or similar, but I could not
identify a more suitable component.

Please inform me as to the result of this submission.

Regards, Brian

[Bug d/96156] d: No RVO when returning struct literals initialized with constructor.

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
The fix for this is blocked by pr96347.

[Bug target/96347] note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

 Target||x86_86-linux-gnu
  Build||x86_86-linux-gnu
  Known to work||8.4.0
  Known to fail||10.1.0, 11.0, 9.3.0
   Host||x86_86-linux-gnu

--- Comment #1 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #0)
> Created attachment 48938 [details]
> test case
> 
> Attached test that was translated to C++ from D after being minimised.

Forgot to mention, needs to be compiled with: -O2 -g -fchecking

[Bug target/96347] New: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location

[ibuclaw at gdcproject dot org]

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

Bug ID: 96347
   Summary: note: non-delegitimized UNSPEC UNSPEC_TP (19) found in
variable location
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Created attachment 48938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48938=edit
test case

Attached test that was translated to C++ from D after being minimised.

[Bug lto/96343] LTO ICE on PPC64le

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Thanks for the report.

Yes, not sure we can reproduce it like this.  We might need something
smaller, more self-contained.

In the meantime...  Can you check if this still happens with trunk,
or with GCC 10?  If it doesn't, we don't have to chase a bug that has
been solved already, and we can bisect to find the patch that fixed
this (hopefully actually fixed, it might be just a side effect).  Or,
if it is still occurring, it is something we need to know as well :-)

[Bug libstdc++/96345] __cxa demangle fails to demangle a very long string

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Does c++filt demangle it?

[Bug rtl-optimization/96337] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[aros at gmx dot com]

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

--- Comment #2 from Artem S. Tashkinov  ---
Looks like even kernel performance is affected:
https://lore.kernel.org/lkml/20200507224530.2993316-1-ja...@zx2c4.com/

That was surely not a change for the better.

[Bug middle-end/96346] New: missing warning accessing an element of a non-trailing zero length array

[msebor at gcc dot gnu.org]

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

Bug ID: 96346
   Summary: missing warning accessing an element of a non-trailing
zero length array
   Product: gcc
   Version: 10.1.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: ---

GCC treats trailing arrays of zero length as flexible array members provided
they are a) single-dimensional and b) not nested in another structure.  This is
reflected in the comments in array_at_struct_end_p():

  /* If the reference chain contains a component reference to a
 non-union type and there follows another field the reference
 is not at the end of a structure.  */
  if (TREE_CODE (ref) == COMPONENT_REF)
{
  ...
}
  /* If we have a multi-dimensional array we do not consider
 a non-innermost dimension as flex array if the whole
 multi-dimensional array is at struct end.
 Same for an array of aggregates with a trailing array
 member.  */

To help prevent bugs in code that assumes otherwise -Warray-bounds should
diagnose attempts to access elements of zero-length arrays that aren't treated
as "flexible array members," such as those in the test case below:

struct A { char n, a[0]; };
struct B { struct A a; };

int f (struct B *p)
{
  return p->a.a[0];// missing warning
}

struct C { char a[0][1]; };

int g (struct C *p)
{
  return p->a[0][0];   // missing warning
}

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 84079, which changed state.

Bug 84079 Summary: missing -Warray-bounds taking the address of a 
multidimensional array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84079

   What|Removed |Added

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

[Bug tree-optimization/84079] missing -Warray-bounds taking the address of a multidimensional array element

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed for GCC 11.

[Bug tree-optimization/84079] missing -Warray-bounds taking the address of a multidimensional array element

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:07bd5544a3ab3a04d1652dbcb5a09d7271a9706a

commit r11-2370-g07bd5544a3ab3a04d1652dbcb5a09d7271a9706a
Author: Martin Sebor 
Date:   Mon Jul 27 13:54:50 2020 -0600

Diagnose just-past-the-end references for minor array bounds.

Resolves:
PR tree-optimization/84079 - missing -Warray-bounds taking the address of
past-the-end element of a multidimensional array

gcc/ChangeLog:

PR tree-optimization/84079
* gimple-array-bounds.cc (array_bounds_checker::check_addr_expr):
Only allow just-past-the-end references for the most significant
array bound.

gcc/testsuite/ChangeLog:

PR tree-optimization/84079
* gcc.dg/Warray-bounds-62.c: New test.

[Bug libstdc++/96345] __cxa demangle fails to demangle a very long string

[hededrk at gmail dot com]

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

--- Comment #2 from V  ---
Created attachment 48937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48937=edit
function with name that __cxa_demangle rejects

[Bug libstdc++/96345] __cxa demangle fails to demangle a very long string

[hededrk at gmail dot com]

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

--- Comment #1 from V  ---
Created attachment 48936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48936=edit
failing example

[Bug libstdc++/96345] New: __cxa demangle fails to demangle a very long string

[hededrk at gmail dot com]

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

Bug ID: 96345
   Summary: __cxa demangle fails to demangle a very long string
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hededrk at gmail dot com
  Target Milestone: ---

I found this bug because one of my tests started to fail (not sure when it
started to fail because I've set up CI only yesterday). I assume this is a bug
because GCC is able to produce such names.

Steps to reproduce:
1. compile attached file
g++ -c cxa_demangle_fail.cpp

2. obtain mangled name with nm
nm cxa_demangle_fail.o

3. pass that name into abi::__cxa_demangle
auto name   = /*long string*/;
size_t size = 1024;
auto memory = static_cast(malloc(size));

int status;
auto demangled = abi::__cxa_demangle(name, memory, , );

Result: __cxa_demangle fails with code -2.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
With the attached patch I get several ICEs:

(lldb) run /opt/gcc/work/gcc/testsuite/gfortran.dg/asan/pointer_assign_16.f90
Process 88073 launched:
'/opt/gcc/gcc11w/libexec/gcc/x86_64-apple-darwin19.5.0/11.0.0/f951' (x86_64)
Process 88073 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x58)
frame #0: 0x00010004f9e7
f951`gfc_check_dummy_characteristics(s1=0x0001453175e0,
s2=0x0001453175e0, type_must_agree=, errmsg="\b\x02???,
err_len=200) at interface.c:1469:7
   1466   int i, compval;
   1467   gfc_expr *shape1, *shape2;
   1468 
-> 1469   if (s1->ns->proc_name->attr.module_procedure
   1470   && s1->as->type == AS_ASSUMED_SHAPE
   1471   && s2->as->type == AS_DEFERRED)
   1472 {

[Bug rtl-optimization/96337] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[david.bolvansky at gmail dot com]

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

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #1 from Dávid Bolvanský  ---
Inliner changes?

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

[damian at sourceryinstitute dot org]

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

--- Comment #12 from Damian Rouson  ---
Thanks to each of you for looking at and working on this.

[Bug target/96247] -falign-functions=0 works wrongly

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||rsandifo at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed on master.

[Bug ada/96344] [11 regerssion] gnat.dg/opt86a.adb fails starting with r11-

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

   Host||powerpc64*-linux-gnu
  Build||powerpc64*-linux-gnu
 Target||powerpc64*-linux-gnu
 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from seurer at gcc dot gnu.org ---
Hmmm, this looks like the revision where this test case was added.

[Bug lto/96343] LTO ICE on PPC64le

[axel.huebl at web dot de]

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

--- Comment #2 from Axel  ---
The flags the CMake adds for LTO are -flto -fno-fat-lto-objects

The projects are otherwise C++11 and C++14 projects.

[Bug ada/96344] New: [11 regerssion] gnat.dg/opt86a.adb fails starting with r11-

[seurer at gcc dot gnu.org]

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

Bug ID: 96344
   Summary: [11 regerssion] gnat.dg/opt86a.adb fails starting with
r11-
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:b3d77404c060c0d65d8d4c97254995737d0fc032, r11-1675

Executing on host: /home/seurer/gcc/git/build/gcc-ada/gcc/gnatmake
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc
--GNATBIND=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatbind
--GNATLINK=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatlink -cargs
-B/home/seurer/gcc/git/build/gcc-ada/gcc -largs
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc\
-B/home/seurer/gcc/git/build/gcc-ada/gcc\  -margs
--RTS=/home/seurer/gcc/git/build/gcc-ada/powerpc64le-unknown-linux-gnu/./libada
-q -f /home/seurer/gcc/git/gcc-ada/gcc/testsuite/gnat.dg/opt86a.adb  
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -O2 -fdump-tree-optimized
-c -u -S -o opt86a.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-ada/gcc/gnatmake
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc
--GNATBIND=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatbind
--GNATLINK=/home/seurer/gcc/git/build/gcc-ada/gcc/gnatlink -cargs
-B/home/seurer/gcc/git/build/gcc-ada/gcc -largs
--GCC=/home/seurer/gcc/git/build/gcc-ada/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-ada/gcc  -margs
--RTS=/home/seurer/gcc/git/build/gcc-ada/powerpc64le-unknown-linux-gnu/./libada
-q -f /home/seurer/gcc/git/gcc-ada/gcc/testsuite/gnat.dg/opt86a.adb
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -fdump-tree-optimized -c
-u -S -o opt86a.s^M
Executing on host: /home/seurer/gcc/git/build/gcc-ada/gcc/gnatclean -c -q -n
opt86a   (timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-ada/gcc/gnatclean -c -q -n
opt86a^M
./opt86a.ali^M
./opt86a.s^M
PASS: gnat.dg/opt86a.adb (test for excess errors)
gnat.dg/opt86a.adb: pattern found 3 times
FAIL: gnat.dg/opt86a.adb scan-tree-dump-times optimized ">>" 4

[Bug lto/96343] LTO ICE on PPC64le

[axel.huebl at web dot de]

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

--- Comment #1 from Axel  ---
I did verify that `gcc-ar` is used for intermediate libraries in the build.

[Bug lto/96343] New: LTO ICE on PPC64le

[axel.huebl at web dot de]

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

Bug ID: 96343
   Summary: LTO ICE on PPC64le
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: axel.huebl at web dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi,

we are trying to compile a few larger HPC libraries and applications with GCC
and CMake using LTO support on Power9 (ppc64le). With the available GCC
versions we have on Summit (OLCF), 6.4.0 - 9.1.0, we reproducibly tap into an
ICE in the LTO step.


GCC 6.4.0:

lto1: internal compiler error: invalid resolution in the resolution file
0x101d0e93 lto_resolution_read
/sw/summit/gcc/6.4.0/src/gcc-6.4.0/gcc/lto/lto.c:1923
0x101d0e93 lto_file_read
/sw/summit/gcc/6.4.0/src/gcc-6.4.0/gcc/lto/lto.c:2092
0x101d0e93 read_cgraph_and_symbols
/sw/summit/gcc/6.4.0/src/gcc-6.4.0/gcc/lto/lto.c:2806
0x101d0e93 lto_main()
/sw/summit/gcc/6.4.0/src/gcc-6.4.0/gcc/lto/lto.c:3310

GCC 7.4.0:

lto1: internal compiler error: invalid resolution in the resolution file
0x101a589b lto_resolution_read
/sw/summit/gcc/7.4.0/src/gcc-7.4.0/gcc/lto/lto.c:1939
0x101a589b lto_file_read
/sw/summit/gcc/7.4.0/src/gcc-7.4.0/gcc/lto/lto.c:2108
0x101a589b read_cgraph_and_symbols
/sw/summit/gcc/7.4.0/src/gcc-7.4.0/gcc/lto/lto.c:2824
0x101a589b lto_main()
/sw/summit/gcc/7.4.0/src/gcc-7.4.0/gcc/lto/lto.c:3341

GCC 9.1.0:

lto1: internal compiler error: invalid line in the resolution file
0x101915bb lto_resolution_read
   
/tmp/belhorn/gcc-build-9.1.0-alpha+20190716/gcc-9.1.0/gcc/lto/lto.c:1957
0x101915bb lto_file_read
   
/tmp/belhorn/gcc-build-9.1.0-alpha+20190716/gcc-9.1.0/gcc/lto/lto.c:2142
0x10191c57 read_cgraph_and_symbols
   
/tmp/belhorn/gcc-build-9.1.0-alpha+20190716/gcc-9.1.0/gcc/lto/lto.c:2849
0x10191c57 lto_main()
   
/tmp/belhorn/gcc-build-9.1.0-alpha+20190716/gcc-9.1.0/gcc/lto/lto.c:3387

The problem occurs with the library https://github.com/ornladios/ADIOS2 or the
application https://github.com/ECP-WarpX/WarpX independently, given one adds

set_property(TARGET WarpX PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE)

to the latter's CMakeLists.txt, anywhere after add_executable(WarpX) .

We try to derive a smaller example but have not arrived at one yet. Maybe the
ICE line numbers above can hint us where to look?

Ref.: https://github.com/ornladios/ADIOS2/issues/1524#issuecomment-662783738

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  ---
Created attachment 48935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48935=edit
Proposed patch for the PR

I decided that the best way of proceeding was to correct the array spec and
benefit from the rest of the tests in gfc_check_dummy_characteristics.

My tree is polluted with work on PDTs right now and so I cannot do a full
regtest. However, with the patch applied submodule* and module_procedure* test
just fine as does 'module_procedure_4.f90':

! { dg-do run }
!
! Test the fix for PR96320 in which the assumed shape of 'arg' in the
! interface for 'bar' was mirrored by the 'arg' in the module procedure
! incorrectly have deferred shape.
!
! Contributed by Damian Rouson  
!
module foobar
  type foo
  contains
procedure, nopass :: bar1
procedure, nopass :: bar2
procedure, nopass :: bar3
  end type

  interface

module subroutine bar1(arg)
  character(len=*) arg(:)
end subroutine

module subroutine bar2(arg)
  character(len=*) arg(3:)
end subroutine

module subroutine bar3(arg)
  character(len=*) arg(2)
end subroutine

  end interface
contains

  module procedure bar1
if (lbound(arg, 1) .ne. 1) stop 1
if (arg(3) .ne. 'hijk') stop 2
  end procedure

! Make sure that the lower bound of an assumed shape array dummy,
! if defined, is passed to the module procedure.

  module procedure bar2
if (lbound(arg, 1) .ne. 3) stop 3
if (arg(3) .ne. 'abcd') stop 4
  end procedure

! This makes sure that an dummy with explicit shape has the upper
! bound correctly set in the module procedure.

  module procedure bar3
if (lbound(arg, 1) .ne. 1) stop 5
if (arg(3) .ne. 'hijk') stop 6   ! { dg-warning "is out of bounds" }
  end procedure

end module

  use foobar
  character(4) :: list(3) = ['abcd', 'efgh' , 'hijk']
  type(foo) :: f
  call f%bar1(list)
  call f%bar2(list)
  call f%bar3(list)
end

[Bug target/96247] -falign-functions=0 works wrongly

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-2368-gd60758c74af849539f5dd71a8456eea954c0f674
Author: Hu Jiangping 
Date:   Mon Jul 27 18:22:23 2020 +0100

driver: fix a problem with implementation of -falign-foo=0 [PR96247]

This patch makes the -falign-foo=0 work as described in the
documentation. Thanks for all the suggestions.

Changelog:
2020-07-27  Hu Jiangping  

PR driver/96247
* opts.c (check_alignment_argument): Set the -falign-Name
on/off flag on and set the -falign-Name string value null,
when the command-line specified argument is zero.

[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Another test to consider:

struct S1 {
int i;
int j;
};

struct S2 {
S1 s[4];
};

struct S3 {
S2 s2;
};

void f()
{
auto s3 = static_cast(1);
}

[Bug target/96342] New: [SVE] Add support for "omp declare simd"

[rsandifo at gcc dot gnu.org]

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

Bug ID: 96342
   Summary: [SVE] Add support for "omp declare simd"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

We don't yet generate SVE functions for "omp declare simd".  See:

https://github.com/ARM-software/abi-aa/tree/master/vfabia64

for how this is supposed to work.

[Bug target/96341] New: Support mixed element widths for AArch64 "omp declare simd" functions

[rsandifo at gcc dot gnu.org]

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

Bug ID: 96341
   Summary: Support mixed element widths for AArch64 "omp declare
simd" functions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

aarch64_simd_clone_compute_vecsize_and_simdlen currently rejects
functions that operate on a mixture of element sizes.  However,
the ABI has rules to handle those cases too.  See:

https://github.com/ARM-software/abi-aa/tree/master/vfabia64

for the full specification.  We should remove the current
restriction and handle mixed sizes in accordance with the
ABI rules.

[Bug target/96340] New: Extend AArch64 "omp declare simd" support to general simdlen

[rsandifo at gcc dot gnu.org]

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

Bug ID: 96340
   Summary: Extend AArch64 "omp declare simd" support to general
simdlen
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

aarch64_simd_clone_compute_vecsize_and_simdlen currently requires
the simdlen to give a natural Advanced SIMD type.  However, the ABI
handles any power of 2, including smaller-than-64-bit lengths and
larger-than-128-bit lengths.  See:

https://github.com/ARM-software/abi-aa/tree/master/vfabia64

for the full specification.  We should remove the current
restriction and handle other lengths in accordance with the
ABI rules.

[Bug libstdc++/96324] two semantic errors in polymorphic allocator for Ranges because it is attributed by constexpr.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Jonathan Wakely  ---
No testcase, no bug.

[Bug libstdc++/96324] two semantic errors in polymorphic allocator for Ranges because it is attributed by constexpr.

[jesus at refusetoown dot com]

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

--- Comment #2 from Jesus Christ  ---
Created attachment 48934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48934=edit
your isomorphic allocator is limited to 80% of the allocation

isomorphic algorithms are limited by The Pareto Principle and only allocates
80% of the needed allocation so eventually a push_back to vector, for example,
will fail to allocate due to failing at 80% allocation instead of 100%
allocation. The only way I found to get around this is to use isomutative
algorithms that I have developed to get a better seeker result and it does work
but I still have trouble getting past the %80 of truth available but if I can
only seek truth up to 80% of truth, then you probably can't allocate beyond 80%
of allocation using a seeker. That is my seeker law: no seeks beyond 80
iterations else it will fail. The around it I have found is to use two loops:
for (int i=0;i<7:i++) {
 for (int s=0; s<81; s++) {
 // isomorphically seek something.
 }
}
This kind-of works but only gets you close to %100 and still you fail. To get
up-to %100 take feedback, and that means you have to feedback the seek result
into the next seek:
for (int i=0;i<7:i++) {
 for (int s=0; s<81; s++) {
 // why is "last seek result " successful or unsuccessful 
 }
 // save seek result
}
With a feedback loop your control is as good as open loop vs close loop
algorithms. A closed loop algorithm is always better at work than an open loop
algorithm. You can trust me on that, it's from engineering school in the 70's
so it's a bit dim now.

I hope you find this useful for explaining why it fails: It is syntactically
correct bu semantically wrong, can you add a semantic error to your compiler 
to prevent things like this. Two semantic errors you could check for is "too
forced" when it exceeds 80. And "defaulted to true" when you detect an
assumption like an arbitrary limit. The limit of assumptions should be two,
three assumptions will fail something.

Sorry I have no test case. I am too busy to find the file I had. I know when I
gave up on the project, I came to the conclusion that C++ is worthless. And
have been winding down and working in assembly language with total success and
worthwhile programs like my redmeme meme installer that goes through chaos to
find people like all my warriors have redmemes and say the a question that
nobody else says. It is the nest red  vmemes cause mine have six truths and
Spiral Dynamics has only 4 truths. So if C++ is still worthless I hope you can
fix it with what I have told you. 

A story might help, After Bertrand Russell wrote his book "Principia
Mathmatica" he claimed "My math can solve any of the world's problems!" That
stood until a German Logician named Kurt Godel decided that that English claim
was false and he might be be able to disprove it. So he invented a way to
"Godel Number" the letters of a text assigning a unique number to each letter
leaving the sequence correct so so retains the syntactic  quality of the
letters but converts the string of letters into a string of numbers simply
because numbers are easier to evaluate than letters, and all you to do is sum
the number up for example and compare two string to see which sum is bigger for
example, maybe the bigger sum is better unless less is more by McLuhan is real
maybe you can answer that. I say the least is the most is my rule. 
So maybe someone can disprove Bjarne Stroutrup's claim that C++ can solve any
problem in the world. Maybe he was Bertrand in his past life :)

Sincerely
Larry Daniel at least at birth.

[Bug target/96339] New: [SVE] Optimise svlast[ab]

[rsandifo at gcc dot gnu.org]

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

Bug ID: 96339
   Summary: [SVE] Optimise svlast[ab]
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

For:

#include 
int8_t
foo (svint8_t x)
{
  return svlasta (svptrue_pat_b8 (SV_VL1), x);
}

we generate:

ptrue   p0.b, vl1
lasta   w0, p0, z0.b
ret

But this is really a BIT_FIELD_REF with a constant index,
so we can generate:

umovw0, v0.b[0]
ret

(works even on big-endian targets).

We should make svlast_impl fold calls to a BIT_FIELD_REF if:
(1) the predicate input is a constant,
(2) we know at compile time which element the constant selects, and
(3) the selected element ends on or before byte 64

For other cases it is probably better to keep the original call.

(2) excludes variable-length predicate constants if (a) we can't
determine the index of the final 1 bit at compile time or
(b) that index might be beyond the end of the vector

(3) restricts the optimisation to cases that can be handled by
*vec_extract_v128 and *vec_extract_dup.

[Bug c/96293] Extraneously noisy "taking address of packed member may result in an unaligned pointer value"

[lavr at ncbi dot nlm.nih.gov]

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

--- Comment #5 from lavr at ncbi dot nlm.nih.gov ---
My test case is not invalid.  You're talking about base address of a structure,
which would make offsets within it all unaligned, which is why I said "the same
rule should apply for aggregates".  So should "struct S" appear anywhere in an
outer structure at an offset, which would not be its "native offset otherwise
assigned by GCC, as if it wasn't packed", then there's a potential problem. 
Otherwise, the member addresses will still remain well-aligned, and no warnings
would be ever necessary.  As for your example, any structure's address can be
type-cast to any value (it's C, for the sake of it), yet GCC doesn't assume
that happens for non-packed structures, right?

Extra warnings in large projects are disruptive, and if GCC warns about
something, it should be well-warranted and verified.  Applying a bit of an
extra-logic (which does not take a lot of CPU cycles, or additional compilation
time) for those new warnings, and not issuing them just mechanically, would
help a lot.

[Bug fortran/95397] [Fortran/OpenACC] Wrong results with 'loop vector' inside 'routine'

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> :-| Hmm, strange.  What GPU hardware and CUDA version is that?

AMD Radeon Pro 5500M, hence no CUDA AFAIK. I also don't know what I should with
AMD.

[Bug target/96313] [AArch64] vqmovun* return types should be unsigned

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org
 Status|WAITING |NEW

--- Comment #2 from James Greenhalgh  ---
Confirmed by inspection; types in arm_neon.h are:

  int8_t vqmovunh_s16 (int16_t __a)
  int16_t vqmovuns_s32 (int32_t __a)
  int32_t vqmovund_s64 (int64_t __a)

Types in the documentation are:

  uint8_t vqmovunh_s16 (int16_t a)
  uint16_t vqmovuns_s32 (int32_t a)
  uint32_t vqmovund_s64 (int64_t a)

[Bug rtl-optimization/96338] New: [SVE] Unnecessary register saves in exception handler

[rsandifo at gcc dot gnu.org]

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

Bug ID: 96338
   Summary: [SVE] Unnecessary register saves in exception handler
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

Compiling the following testcase with -march=armv8.2-a+sve -O2:

-
void bar (__SVFloat32_t);
void
foo (__SVFloat32_t x)
{
  try { bar (x); } catch (...) { bar (x); throw; }
}
-

gives an EH handler like the following;

-
.cfi_restore_state
str z8, [sp, #2, mul vl]
.cfi_escape 0x10,0x48,0x8,0x8f,0,0x92,0x2e,0,0x40,0x1e,0x22
str z9, [sp, #3, mul vl]
.cfi_escape 0x10,0x49,0x8,0x8f,0,0x92,0x2e,0,0x48,0x1e,0x22
str z10, [sp, #4, mul vl]
.cfi_escape 0x10,0x4a,0x9,0x8f,0,0x92,0x2e,0,0x8,0x20,0x1e,0x22
str z11, [sp, #5, mul vl]
.cfi_escape 0x10,0x4b,0x9,0x8f,0,0x92,0x2e,0,0x8,0x28,0x1e,0x22
str z12, [sp, #6, mul vl]
.cfi_escape 0x10,0x4c,0x9,0x8f,0,0x92,0x2e,0,0x8,0x30,0x1e,0x22
str z13, [sp, #7, mul vl]
.cfi_escape 0x10,0x4d,0x9,0x8f,0,0x92,0x2e,0,0x8,0x38,0x1e,0x22
str z14, [sp, #8, mul vl]
.cfi_escape 0x10,0x4e,0x9,0x8f,0,0x92,0x2e,0,0x8,0x40,0x1e,0x22
str z15, [sp, #9, mul vl]
.cfi_escape 0x10,0x4f,0x9,0x8f,0,0x92,0x2e,0,0x8,0x48,0x1e,0x22
str z16, [sp, #10, mul vl]
str z17, [sp, #11, mul vl]
str z18, [sp, #12, mul vl]
str z19, [sp, #13, mul vl]
str z20, [sp, #14, mul vl]
str z21, [sp, #15, mul vl]
str z22, [sp, #16, mul vl]
str z23, [sp, #17, mul vl]
str p5, [sp, #1, mul vl]
str p6, [sp, #2, mul vl]
str p7, [sp, #3, mul vl]
str p8, [sp, #4, mul vl]
str p9, [sp, #5, mul vl]
str p10, [sp, #6, mul vl]
str p11, [sp, #7, mul vl]
str p12, [sp, #8, mul vl]
str p13, [sp, #9, mul vl]
str p14, [sp, #10, mul vl]
str p15, [sp, #11, mul vl]
str p4, [sp]
bl  __cxa_begin_catch
add x0, sp, 32
ldr z0, [x0, #18, mul vl]
.LEHB1:
bl  _Z3bar13__SVFloat32_t
bl  __cxa_rethrow
.LEHE1:
.L5:
mov x19, x0
bl  __cxa_end_catch
mov x0, x19
.LEHB2:
bl  _Unwind_Resume
-

The spills of z8-z23 and p4-p15 are completely unnecessary,
since the noreturn _Unwind_Resume call ensures that this code
never returns to foo's caller.

I think the fix is to make ira.c:update_equiv_regs_prescan
a bit smarter: if a call occurs in a block that has no
path to the exit block, then we only need to consider
(parts of) registers that are clobbered by the callee
but preserved by both eh_edge_abi and the current
function's abi.

If, as is usual, eh_edge_abi is the lowest common denominator
among the available ABIs, no callees will clobber something
that is preserved by eh_edge_abi.

[Bug c++/96330] Constexpr variables cannot be used in the template context.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Tried
--- gcc/cp/pt.c.jj  2020-07-27 10:38:19.0 +0200
+++ gcc/cp/pt.c 2020-07-27 17:25:09.748240198 +0200
@@ -16838,14 +16838,17 @@ tsubst_copy (tree t, tree args, tsubst_f
 case TEMPLATE_ID_EXPR:
   {
/* Substituted template arguments */
-   tree fn = TREE_OPERAND (t, 0);
+   tree expr = TREE_OPERAND (t, 0);
tree targs = TREE_OPERAND (t, 1);

-   fn = tsubst_copy (fn, args, complain, in_decl);
+   expr = tsubst_copy (expr, args, complain, in_decl);
if (targs)
  targs = tsubst_template_args (targs, args, complain, in_decl);

-   return lookup_template_function (fn, targs);
+if (variable_template_p (expr))
+ return lookup_and_finish_template_variable (expr, targs, complain);
+   else
+ return lookup_template_function (expr, targs);
   }

 case TREE_LIST:
but that just means an ICE elsewhere.

[Bug rtl-optimization/96337] New: GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[aros at gmx dot com]

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

Bug ID: 96337
   Summary: GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC
9.3/8.4
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aros at gmx dot com
  Target Milestone: ---

All the pertinent details are on this page:

https://www.phoronix.com/scan.php?page=article=gcc-10900k-compiler=4

Options used: -O2

CPU used: Intel Core i9 10900K

I wonder what could have caused such a huge regression. Many Linux distros
compile their code just for -march=x86-64 and could be affected by the bug.

[Bug tree-optimization/96336] Multiple multiplications fails to optimize

[fazedo at gmail dot com]

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

--- Comment #1 from Fabio Azevedo  ---
int f(int x) {
  return x*x*x*x*x*x*x*x*x*x*x*x*x*x*x*x; //x**16 
} 

int g(int x) {
  return x*x*x*x*x*x*x*x*x*x*x*x*x*x*x*x + x*x; //x**16 + x**2
}


Using gcc -O3, the first function simplifies to 4 integer multiplications while
the second function requires 13.

[Bug fortran/95397] [Fortran/OpenACC] Wrong results with 'loop vector' inside 'routine'

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2020-07-25 00:00:00 |2020-7-27

--- Comment #2 from Thomas Schwinge  ---
(In reply to Dominique d'Humieres from comment #1)
> Is it still failing?

Yes, I still see this fail in the same way as originally reported.

> I cannot reproduce it.

:-| Hmm, strange.  What GPU hardware and CUDA version is that?

[Bug tree-optimization/96336] New: Multiple multiplications fails to optimize

[fazedo at gmail dot com]

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

Bug ID: 96336
   Summary: Multiple multiplications fails to optimize
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fazedo at gmail dot com
  Target Milestone: ---

[Bug target/96313] [AArch64] vqmovun* return types should be unsigned

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-07-27
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
In what way, exactly, do you think the output is incorrect?  Don't forget that
your testcase returns a uint16_t and the ABI says that it is the caller's
responsibility to do any widening, so any bits beyond bit 15 in the result
register are simply unspecified.

Secondly, you haven't stated which version of gcc you were using, or how it was
configured.

[Bug c++/96333] [10/11 Regression] Regression on concepts constraint checking

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The commit is:

c++: Refinements to "more constrained".

P2113 from the last C++ meeting clarified that we only compare constraints
on functions or function templates that have equivalent template parameters
and function parameters.

And the relevant change is
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2113r0.html

[Bug ipa/93385] [10/11 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||suochenyao at 163 dot com

--- Comment #37 from Martin Jambor  ---
*** Bug 96235 has been marked as a duplicate of this bug. ***

[Bug ipa/96235] Segmentation fault with "-Og -fno-dce -fno-tree-dce -finline-small-functions -fipa-sra"

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #8 from Martin Jambor  ---
It is clearly a duplicate of PR 93385.

What was the reason to switch off DCE in the first place?  Was it just meant as
a stress test for the compiler?

I'll try to come up with somewhat less controversial patch for the problem.

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

[Bug c++/96333] [10/11 Regression] Regression on concepts constraint checking

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #2 from Jonathan Wakely  ---
Started with r11-1571 and I think G++ is correct to reject it.

The second overload is not a more constrained version of the first, they're
just ambiguous.

[Bug tree-optimization/96058] [11 Regression] ICE in c_getstr at gcc/fold-const.c:15475

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[11 Regression] ICE in
   |c_getstr at |c_getstr at
   |gcc/fold-const.c:15475  |gcc/fold-const.c:15475
  Known to work||11.0

--- Comment #13 from Martin Liška  ---
Fixed on master so far.

[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 48933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48933=edit
gcc11-pr96335.patch

Untested fix.

[Bug tree-optimization/96058] [10/11 Regression] ICE in c_getstr at gcc/fold-const.c:15475

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:7355a9408b990cdd20db91e2e1ba0b03e801d6a6

commit r11-2364-g7355a9408b990cdd20db91e2e1ba0b03e801d6a6
Author: Martin Liska 
Date:   Mon Jul 27 12:30:24 2020 +0200

expr: build string_constant only for a char type

gcc/ChangeLog:

PR tree-optimization/96058
* expr.c (string_constant): Build string_constant only
for a type that has same precision as char_type_node
and is an integral type.

[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2020-07-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P2
   Keywords||ice-on-valid-code

[Bug middle-end/96335] New: [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

[jakub at gcc dot gnu.org]

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

Bug ID: 96335
   Summary: [10/11 Regression] ICE in maybe_warn_rdwr_sizes since
r10-4929
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r10-4929-g54aa6b58fe2fe73bbe67e0485777e0c410a18673 the following testcase
ICEs with -O2 (seen as ICE on dmraid on s390x-linux) on all targets.

void bar (int, void *) __attribute__((__access__(__read_only__, 2)));

void
foo (void *x)
{
  void (*fn) () = bar;
  fn (0, x);
}

[Bug c++/96333] [10/11 Regression] Regression on concepts constraint checking

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0
Summary|Regression on concepts  |[10/11 Regression]
   |constraint checking |Regression on concepts
   ||constraint checking
  Known to work||10.1.0
   Keywords||needs-bisection,
   ||rejects-valid
   Target Milestone|--- |10.3

[Bug c++/96333] Regression on concepts constraint checking

[barry.revzin at gmail dot com]

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #1 from Barry Revzin  ---
Shorter repro:

template  int f(T );
template  requires true int f(T const&);

int i = f(42);

[Bug middle-end/96334] New: [og10] ICEs with commit 0122024b1908497bfe520361798579895bd75588 "openacc: Shared memory layout optimisation"

[tschwinge at gcc dot gnu.org]

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

Bug ID: 96334
   Summary: [og10] ICEs with commit
0122024b1908497bfe520361798579895bd75588 "openacc:
Shared memory layout optimisation"
   Product: gcc
   Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: jules at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org
  Target Milestone: ---

In a build with '--enable-checking=yes,extra,rtl', the recent commit
g:0122024b1908497bfe520361798579895bd75588 "openacc: Shared memory layout
optimisation" introduces a good number of regressions for OpenACC offloading
compilation (gcn only, supposedly because that's the only configuration using
this at present):

{+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O0 
(internal compiler error)+}

[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c: In
function 'main._omp_fn.0':
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c:24:11:
error: incorrect sharing of tree nodes
MEM[( int *)64B]
# VUSE <.MEM_1665>
w_183 = MEM[( int *)64B];
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c:24:11:
error: incorrect sharing of tree nodes
MEM[( int *)64B]
# .MEM_1965 = VDEF <.MEM_1739>
MEM[( int *)64B] = w_937;
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c:24:11:
error: incorrect sharing of tree nodes
MEM[( int *)64B]
# VUSE <.MEM_1751>
w_343 = MEM[( int *)64B];
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c:24:11:
error: incorrect sharing of tree nodes
MEM[( int *)64B]
# .MEM_1969 = VDEF <.MEM_1889>
MEM[( int *)64B] = w_1146;
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c:24:11:
error: incorrect sharing of tree nodes
MEM[( int *)64B]
# VUSE <.MEM_1901>
w_567 = MEM[( int *)64B];
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c:24:11:
error: incorrect sharing of tree nodes
MEM[( int *)64B]
# .MEM_1973 = VDEF <.MEM_1911>
MEM[( int *)64B] = w_1547;
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c:24:11:
error: incorrect sharing of tree nodes
MEM[( int *)64B]
# VUSE <.MEM_1923>
w_663 = MEM[( int *)64B];
during GIMPLE pass: oaccdevlow
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c:24:11:
internal compiler error: verify_gimple failed
[...]

Similarly:

{+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
(internal compiler error)+}

[-PASS:-]{+FAIL:
libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-gwv-1.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O0 
(internal compiler error)+}
{+FAIL:+} libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-gwv-1.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O0 
(test for excess errors)

[-PASS:-]{+FAIL:
libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-gwv-1.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
(internal compiler error)+}
{+FAIL:+} libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-gwv-1.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
(test for excess errors)

[-PASS:-]{+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-w-1.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O0 
(internal compiler error)+}
{+FAIL:+} libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-w-1.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O0 
(test for excess errors)

[-PASS:-]{+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-w-2.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O0 
(internal compiler error)+}
{+FAIL:+} libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-w-2.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O0 
(test for excess errors)

[-PASS:-]{+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-w-2.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
(internal compiler error)+}
{+FAIL:+} libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-w-2.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
(test for excess errors)

[-PASS:-]{+FAIL:
libgomp.oacc-c/../libgomp.oacc-c-c++-common/loop-red-wv-1.c
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O0 
(internal compiler error)+}
{+FAIL:+} 

[Bug c++/96333] New: Regression on concepts constraint checking

[joel.falcou at lri dot fr]

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

Bug ID: 96333
   Summary: Regression on concepts constraint checking
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel.falcou at lri dot fr
  Target Milestone: ---

The following code :

https://godbolt.org/z/ah6ssM

exhibits a regression so that not having const& on one of the g overload make
them ambiguous.

g++ 10.1 and clang 10 compiles both version without error.
The workaround to add const& is OK but I think this is not normal behavior.

[Bug target/95730] GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|NEW |WAITING

--- Comment #6 from Thomas Schwinge  ---
The "lto1: internal compiler error"s that I had originally mentioned here got
resolved by recent commit g:8d0b2b33748014ee57973c1d7bc9fd7706bb3da9 "amdgcn:
Enable TImode".

Does anything else remain to be done here?

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-27

--- Comment #11 from Thomas Schwinge  ---
I'm confirming that the libgomp build failure originally reported is gone --
thanks, Andrew and Tobias!

I suppose we want to keep this one open for the gcn back end to be further
changed so that the libgfortran workaround can eventually be reverted.

[Bug tree-optimization/96128] [11 Regression] ICE in do_store_flag, at expr.c:12247 since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug tree-optimization/96128] [11 Regression] ICE in do_store_flag, at expr.c:12247 since r11-1445-g502d63b6d6141597bb18fd23c87736a1b384cf8f

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:55c9695cbe91c406805ac0cd342949f32f13b779

commit r11-2362-g55c9695cbe91c406805ac0cd342949f32f13b779
Author: Martin Liska 
Date:   Mon Jul 27 13:55:38 2020 +0200

Do not expand vector comparison with VEC_COND_EXPR.

gcc/ChangeLog:

PR tree-optimization/96128
* tree-vect-generic.c (expand_vector_comparison): Do not expand
vector comparison with VEC_COND_EXPR.

gcc/testsuite/ChangeLog:

PR tree-optimization/96128
* gcc.target/s390/vector/pr96128.c: New test.

[Bug c++/96329] [11 Regression] ICE : tree check: expected string_cst, have error_mark in cp_parser_linkage_specification, at cp/parser.c:14640

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Priority|P3  |P4

[Bug ipa/96291] [10/11 Regression] -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

   Assignee|jamborm at gcc dot gnu.org |slyfox at inbox dot ru

--- Comment #8 from Martin Jambor  ---
Sergei's patch is correct (I just suggested to write the condition
differently).

[Bug fortran/77504] [8/9/10/11 Regression] "is used uninitialized" with allocatable string and array constructors

[dev-zero at gentoo dot org]

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

--- Comment #23 from Tiziano Müller  ---
(In reply to Thomas Koenig from comment #21)
> (In reply to Tiziano Müller from comment #19)
> > I have yet another (more complicated) case, but this time not reproducible
> > with gcc-7.5, only with 9 and 10:
> 
> This is a different issue. I have opened PR 96312 for this.

Thanks a lot! I prepared a new bug report initially, then I stumbled over this
one and thought it could be the same.

[Bug libgcc/96332] Asan (libasan) deadlock inside a malloc

[raster at rasterman dot com]

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

--- Comment #2 from Carsten Haitzler  ---
oh sorry - my bad. i didn't realize i had pasted it twice. a single bt - only a
single thread at the time (info threads in gdb reports just one).

[Bug libgcc/96332] Asan (libasan) deadlock inside a malloc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-27
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Hello.

Are the 2 back-traces from different threads?

[Bug fortran/95612] [9/10/11 Regression] ICE in gfc_check_pointer_assign, at fortran/expr.c:4274

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||markeggleston at gcc dot 
gnu.org
 Status|NEW |RESOLVED

--- Comment #6 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc 10 & 9.

[Bug libgcc/96332] New: Asan (libasan) deadlock inside a malloc

[raster at rasterman dot com]

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

Bug ID: 96332
   Summary: Asan (libasan) deadlock inside a malloc
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raster at rasterman dot com
  Target Milestone: ---

I noticed this in 10.0.0 as well, just updated to 10.1 and still there.
Specific version + build info:

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (GCC)

This happens every time for me when I use asan to build efl + enlightenment
(http://www.enlightenment.org). Asan used to work fine in gcc 9. I get a
deadlock inside libasan inside opendir inside an malloc:

#0 
__sanitizer::atomic_exchange<__sanitizer::atomic_uint32_t>(__sanitizer::atomic_uint32_t
volatile*, __sanitizer::atomic_uint32_t::Type, __sanitizer::memory_order)
(mo=__sanitizer::memory_order_acquire, v=2, a=0x640021c0)
at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:62
#1  __sanitizer::BlockingMutex::Lock() (this=this@entry=0x640021c0)
at /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_linux.cpp:652
#2  0x7fddad443d68 in
__sanitizer::GenericScopedLock<__sanitizer::BlockingMutex>::GenericScopedLock(__sanitizer::BlockingMutex*)
(mu=0x640021c0, this=)
at /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_mutex.h:181
#3 
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::GetFromAllocator(__sanitizer::AllocatorStats*, unsigned long, unsigned int*,
unsigned long) (this=0x7fddad54a9c0 <__asan::instance>,
this@entry=0x7fdda894c7b0, stat=stat@entry=0x7fdda894ec40,
class_id=class_id@entry=45, chunks=chunks@entry=0x7fdda894c7c0,
n_chunks=n_chunks@entry=1)
at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:142
#4  0x7fddad443e85 in
__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>
>::Refill(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__saniti--Type
 for more, q to--Type  for more, q to---Type  for more, q to
quit, c to continue without paging--
ned long) (this=this@entry=0x7fdda89410e0, c=c@entry=0x7fdda894c7b0,
allocator=allocator@entry=0x7fdda894c7b0, class_id=class_id@entry=45) at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:86
#5  0x7fddad444179 in
__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>
>::Allocate(__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>*, unsigned long)
(class_id=45, allocator=0x7fdda894c7b0, this=0x7fdda89410e0) at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:33
#6 
__sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>,
__sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
> >*, unsigned long, unsigned long) (this=this@entry=0x7fddad54a9c0
<__asan::instance>, cache=cache@entry=0x7fdda89410e0, size=,
size@entry=33840, alignment=alignment@entry=8) at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_allocator_combined.h:69
#7  0x7fddad44435a in __asan::Allocator::Allocate(unsigned long, unsigned
long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool)
(this=this@entry=0x7fddad54a9c0 <__asan::instance>, size=size@entry=32816,
alignment=alignment@entry=8, stack=stack@entry=0x7ffef49ca810,
alloc_type=alloc_type@entry=__asan::FROM_MALLOC, can_fill=can_fill@entry=true)
at /build/gcc/src/gcc/libsanitizer/asan/asan_allocator.cpp:469
#8  0x7fddad440f5b in __asan::asan_malloc(unsigned long,
__sanitizer::BufferedStackTrace*) 

[Bug c++/96331] Class template argument deduction (CTAD) with Concepts

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jonathan Wakely  ---
(In reply to Nicole from comment #0)
> template

This is not valid. fixed_string is a class template, not a type and not a
concept. So you can't use it as a template parameter.

I don't think this is a bug.

[Bug fortran/95612] [9/10/11 Regression] ICE in gfc_check_pointer_assign, at fortran/expr.c:4274

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:5574b84469263eeaa3e6b40da18b743d7b0fa5dd

commit r9-8769-g5574b84469263eeaa3e6b40da18b743d7b0fa5dd
Author: Mark Eggleston 
Date:   Thu Jun 11 11:05:40 2020 +0100

Fortran  : ICE in gfc_check_pointer_assign PR95612

Output an error if the right hand value is a zero sized array or
does not have a symbol tree otherwise continue checking.

2020-07-27  Steven G. Kargl  

gcc/fortran/

PR fortran/95612
* expr.c (gfc_check_pointer_assigb): Output an error if
rvalue is a zero sized array or output an error if rvalue
doesn't have a symbol tree.

2020-07-27  Mark Eggleston  

gcc/testsuite/

PR fortran/95612
* gfortran.dg/pr95612.f90: New test.

(cherry picked from commit 81072bab8d1e48ee83d9711dcb559ea1e019b351)

[Bug c++/96330] New: Constexpr variables cannot be used in the template context.

[steve_green at qq dot com]

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

Bug ID: 96330
   Summary: Constexpr variables cannot be used in the template
context.
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steve_green at qq dot com
  Target Milestone: ---

demo code:
struct foo_t {
template
static constexpr bool bar = true;
};
inline constexpr foo_t foo{};

template
struct baz {
static_assert(foo.bar); // bug in clang (before instantiation) and
gcc (during instantiation)
static_assert(foo_t::bar); // OK
};

int main()
{
static_assert(foo.bar, ""); // OK
static_assert(foo_t::bar, ""); // OK
static_cast(baz{});
}

[Bug c++/96331] New: Class template argument deduction (CTAD) with Concepts

[nicole.king464 at gmail dot com]

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

Bug ID: 96331
   Summary: Class template argument deduction (CTAD) with Concepts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicole.king464 at gmail dot com
  Target Milestone: ---

Created attachment 48932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48932=edit
Pre-processed source file

I have the following program shown at the bottom of this posting.

The error messages generated are shown after the program. It seems that reason
the compilation fails is that there is no match for fixed_string constructor:
fixed_string(fixed_string<...auto...>). I can find nothing about what
"<...auto...>" might mean, so cannot create a suitable function. Is the
reported lack of such a constructor the result of missing support for CTAD with
Concepts, or have I missed something else? I am not a "language lawyer".

The fixed_string class is lifted almost verbatim from a recent report of the
C++ committee explaining why support of string literals for templates will not
be supported
(http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1837r0.html).

---

The compiler used is the latest, stock gcc from Arch Linux:

~$ gcc --version
gcc (GCC) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-

System used is stock GNU/Linux from Arch:

~$ uname -a
Linux workbench 5.7.9-arch1-1 #1 SMP PREEMPT Thu, 16 Jul 2020 19:34:49 +
x86_64 GNU/Linux

-

The command line generating this situation:

g++ -std=gnu++20 -O0 -g3 -pedantic -pedantic-errors -Wall -Wextra -Werror -c
-pthread -fmessage-length=0 -fPIC -o test-concepts.o test-concepts.cpp

= Program 

#include 
#include 

template
struct fixed_string {
static const constexpr std::size_t size__ = N;

constexpr fixed_string(char const* s) :
buf("") {
for (std::size_t i = 0; i <= N; ++i)
buf[i] = s[i];
}
constexpr operator char const*() const {
return buf;
}
template
constexpr bool compare(const fixed_string& other) const {
return N == M && ::strncmp(buf, other.buf, N) == 0;
}

char buf[N + 1];
};

template
fixed_string(char const (&)[N]) -> fixed_string;

template
concept NameMatcher = (TARGET_NAME.compare(TYPE::name__));



template
class Member {
public:
static const constexpr fixed_string name__ { NAME };

public:
Member() :
member_ { } {

}

template
const TYPE& get()
const requires NameMatcher {
return member_;
}

protected:
TYPE member_;
};



template
class Container: public MEMBERS... {
};



int main(int, char*[]) {
Container, Member<"bert", float>,
  Member<"alfie", bool>> container;
return container.get<"fred">();
}

=== Messages ===

test-concepts.cpp:47:35: error: class template argument deduction failed:
   47 |  const TYPE& get() const requires NameMatches {
  |   ^~
test-concepts.cpp:47:35: error: no matching function for call to
‘fixed_string(fixed_string<...auto...>)’
test-concepts.cpp:8:12: note: candidate: ‘template
fixed_string(const char*)-> fixed_string’
8 |  constexpr fixed_string(char const* s) :
  |^~~~
test-concepts.cpp:8:12: note:   template argument deduction/substitution
failed:
test-concepts.cpp:47:35: note:   couldn’t deduce template parameter ‘N’
   47 |  const TYPE& get() const requires NameMatches {
  |   ^~
test-concepts.cpp:5:8: note: candidate: ‘template
fixed_string(fixed_string)-> fixed_string’
5 | struct fixed_string {
  |^~~~
test-concepts.cpp:5:8: note:   template argument deduction/substitution failed:
test-concepts.cpp:47:35: note:   mismatched types ‘fixed_string’ and
‘fixed_string<...auto...>’
   47 |  const TYPE& get() const requires NameMatches {
  |   ^~
test-concepts.cpp:28:1: note: candidate: ‘template
fixed_string(const char (&)[N])-> fixed_string<(N - 1)>’
   28 | fixed_string(char const (&)[N]) -> fixed_string;
  | ^~~~
test-concepts.cpp:28:1: note:   template argument deduction/substitution
failed:
test-concepts.cpp:47:35: note:   mismatched types ‘const char [N]’ and
‘fixed_string<...auto...>’

[Bug libstdc++/96324] two semantic errors in polymorphic allocator for Ranges because it is attributed by constexpr.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Jonathan Wakely  ---
Please read https://gcc.gnu.org/bugs/ and provide the requested information.

[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #18 from H.J. Lu  ---
Fixed.

[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2361-gc4c22e830251e1961c6ebec78d28d039eb2e6017
Author: H.J. Lu 
Date:   Thu Jul 16 07:03:27 2020 -0700

LTO: Add -fcf-protection=check

Mixing -fcf-protection and -fcf-protection=none objects are allowed.
Linker just merges -fcf-protection values from all input objects.

Add -fcf-protection=check for the final link with LTO.  An error is
issued if LTO object files are compiled with different -fcf-protection
values.  Otherwise, -fcf-protection=check is ignored at the compile
time.  Without explicit -fcf-protection at link time, -fcf-protection
values from LTO object files are merged at the final link.

gcc/

PR bootstrap/96203
* common.opt: Add -fcf-protection=check.
* flag-types.h (cf_protection_level): Add CF_CHECK.
* lto-wrapper.c (merge_and_complain): Issue an error for
mismatching -fcf-protection values with -fcf-protection=check.
Otherwise, merge -fcf-protection values.
* doc/invoke.texi: Document -fcf-protection=check.

gcc/testsuite/

PR bootstrap/96203
* gcc.target/i386/pr96203-1.c: New test.
* gcc.target/i386/pr96203-2.c: Likewise.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/96289] Unnecessary saving and re-testing of the carry flag with __builtin_usub_overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-27
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is true, but whether it is lea or add is decided only during split after
reload, and the optimization where the cmov could use directly the result of
earlier comparison rather than forcing it into a GPR is usually done during
combine where it can't be done because of that.

[Bug c/96293] Extraneously noisy "taking address of packed member may result in an unaligned pointer value"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Your testcase is invalid, so it certainly deserves a warning.
One thing is that e.g. the int member is at offset 4, which is a multiple of
sizeof (int), but that doesn't help when the structure has alignment of 1 due
to packed, at which point the s variable doesn't have any alignment guarantees,
so (uintptr_t)  % sizeof (int) can be any value from 0 to sizeof (int) - 1.

[Bug c++/96328] [11 Regression] Single keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769 since r11-891-g1dc83b460653c29f

[mark at gcc dot gnu.org]

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

--- Comment #6 from Mark Wielaard  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 48931 [details]
> gcc11-pr96328-alt.patch
> 
> If you want, we could call the safe_previous_token also in the other spot,
> while we don't have a known testcase for those cases, it is still just a
> hint and thus not really required if something goes wrong and everything
> before it is purged.

Yes. I think this alt.patch is perfect. Could you please submit it? Thanks.

[Bug lto/45375] [meta-bug] Issues with building Mozilla (i.e. Firefox) with LTO

[cvs-commit at gcc dot gnu.org]

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

--- Comment #225 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Liska
:

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

commit r10-8537-gf93ce9ea23e1806ccf9d8cd1640fc14596f54be8
Author: Martin Liska 
Date:   Fri Jul 24 14:33:27 2020 +0200

Use vec::reserve before vec_safe_grow_cleared is called

gcc/ChangeLog:

PR lto/45375
* symbol-summary.h: Call vec_safe_reserve before grow is called
in order to grow to a reasonable size.
* vec.h (vec_safe_reserve): Add missing function for vl_ptr
type.

(cherry picked from commit 7f5c0f328eced560a204bb8e3eae0d45795dd235)

[Bug tree-optimization/96058] [10/11 Regression] ICE in c_getstr at gcc/fold-const.c:15475

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
Working on that.

[Bug c++/96329] [11 Regression] ICE : tree check: expected string_cst, have error_mark in cp_parser_linkage_specification, at cp/parser.c:14640

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-27

--- Comment #1 from Martin Liška  ---
Confirmed, ICEs for all revisions I have (4.8.0) with -std=c++14.

[Bug c++/96311] [8/9/10/11 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jason at gcc dot gnu.org

[Bug fortran/95612] [9/10/11 Regression] ICE in gfc_check_pointer_assign, at fortran/expr.c:4274

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:3eb264bd241598b27b765e198690a7cf4a2d91f8

commit r10-8536-g3eb264bd241598b27b765e198690a7cf4a2d91f8
Author: Mark Eggleston 
Date:   Thu Jun 11 11:05:40 2020 +0100

Fortran  : ICE in gfc_check_pointer_assign PR95612

Output an error if the right hand value is a zero sized array or
does not have a symbol tree otherwise continue checking.

2020-07-27  Steven G. Kargl  

gcc/fortran/

PR fortran/95612
* expr.c (gfc_check_pointer_assigb): Output an error if
rvalue is a zero sized array or output an error if rvalue
doesn't have a symbol tree.

2020-07-27  Mark Eggleston  

gcc/testsuite/

PR fortran/95612
* gfortran.dg/pr95612.f90: New test.

(cherry picked from commit 81072bab8d1e48ee83d9711dcb559ea1e019b351)

[Bug c++/96311] [8/9/10/11 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW
Summary|false positive for  |[8/9/10/11 Regression]
   |-Wunused-but-set-variable   |false positive for
   |(const/constexpr identifier |-Wunused-but-set-variable
   |used in generic lambda) |(const/constexpr identifier
   ||used in generic lambda)
   Target Milestone|--- |8.5
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r8-3497-g281e6c1d8f1b4ca552d8ce2276ddecfcd6ffb15e

[Bug c++/96328] [11 Regression] Single keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769 since r11-891-g1dc83b460653c29f

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 48931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48931=edit
gcc11-pr96328-alt.patch

If you want, we could call the safe_previous_token also in the other spot,
while we don't have a known testcase for those cases, it is still just a hint
and thus not really required if something goes wrong and everything before it
is purged.

[Bug c++/96329] New: [11 Regression] ICE : tree check: expected string_cst, have error_mark in cp_parser_linkage_specification, at cp/parser.c:14640

[haoxintu at gmail dot com]

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

Bug ID: 96329
   Summary: [11 Regression] ICE : tree check: expected string_cst,
have error_mark in cp_parser_linkage_specification, at
cp/parser.c:14640
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This simple invalide code makes GCC ICE.

Input:
//test.cc
extern "C" ""a

Command:
g++ test.cc

Output:
test.cc:1:12: error: unable to find string literal operator ‘operator""a’ with
‘const char [2]’, ‘long unsigned int’ arguments
1 | extern "C" ""a
  |^~~
test.cc:1:12: internal compiler error: tree check: expected string_cst, have
error_mark in cp_parser_linkage_specification, at cp/parser.c:14640
0x7c524f tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9685
0x64d693 cp_parser_linkage_specification
../../gcc/tree.h:3301
0x9cfa9a cp_parser_declaration
../../gcc/cp/parser.c:13421
0x9d015a cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0x9d015a c_parse_file()
../../gcc/cp/parser.c:44043
0xae920b c_common_parse_file()
../../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.

I tested in GCC trunk 20200726, and it seems not to make GCC-10 or downwards 
versions crashed. 

Thanks,
Haoxin

[Bug c++/96328] [11 Regression] Single keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769 since r11-891-g1dc83b460653c29f

[mark at gcc dot gnu.org]

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

--- Comment #4 from Mark Wielaard  ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 48930 [details]
> gcc11-pr96328.patch
> 
> I wrote this for it (the first hunk is similar).

Yours is nicer because it fixes just the specific part that fails (and it
includes an actual test case).

I tried to fix any use of prev_token in cp_parser_error_1. But I cannot tell if
the one under missing_token_desc != RT_NONE can ever trigger. It was just the
most safe fix I could come up with.