[Bug c++/95618] [11 Regression] ICE in remap_type_1, at tree-inline.c:607

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Fixed on master with r11-1122-gef41587df9839d1d.

[Bug target/95621] Add CET(PTA_SHSTK) to march=tigerlake

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-10
 Status|UNCONFIRMED |NEW
 CC||hjl at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug lto/95620] [10/11 Regression] relocation truncated to fit: R_X86_64_PC32 against `.bss'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
So we basically change assembly in the following way:

$ diff -u good.s bad.s -U999
--- good.s  2020-06-09 23:37:35.755366723 +0200
+++ bad.s   2020-06-09 23:37:36.771361476 +0200
@@ -1,13 +1,13 @@
.file   ""
.text
.globl  main
.type   main, @function
 main:
 .LFB1:
movlb(%rip), %edx
 .LFE1:
.size   main, .-main
-   .local  b
-   .comm   b,4,4
.local  a
.comm   a,2430270464
+   .local  b
+   .comm   b,4,4

and logically the relocation for 'b(%rip)' now has to go over the huge 'a'
array.
It's invalid to me, I would recommend using -mcmodel=large.

[Bug target/95621] New: Add CET(PTA_SHSTK) to march=tigerlake

[lili.cui at intel dot com]

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

Bug ID: 95621
   Summary: Add CET(PTA_SHSTK) to march=tigerlake
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lili.cui at intel dot com
  Target Milestone: ---

For intel TigerLake need support CET, add PTA_SHSTK to march=tigerlake.

[Bug fortran/95613] ICE in main_block_label, at tree-cfg.c:1455

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4

--- Comment #2 from kargl at gcc dot gnu.org ---
Fortran 66 has not been the standard for 54 years.  Time to enforce numbered
constraints in the Fortran 2018 (and older) standard.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 280157)
+++ gcc/fortran/resolve.c   (working copy)
@@ -10193,12 +10200,16 @@ resolve_branch (gfc_st_label *label, gfc_code *code)
   return;
 }

-  /* The label is not in an enclosing block, so illegal.  This was
- allowed in Fortran 66, so we allow it as extension.  No
- further checks are necessary in this case.  */
-  gfc_notify_std (GFC_STD_LEGACY, "Label at %L is not in the same block "
- "as the GOTO statement at %L", &label->where,
- &code->loc);
+  /* F2018: C1169 (R1157) The label shall be the statement label of a
+ branch target statement that appears in the same inclusive scope
+ as the goto-stmt.
+
+ F2018: C1170 (R1158) Each label in label-list shall be the statement
+ label of a branch target statement that appears in the same inclusive
+ scope as the computed-goto-stmt.  */
+
+  gfc_error ("Label at %L is not in the same block as the GOTO statement "
+"at %L", &label->where, &code->loc);
   return;
 }

[Bug libstdc++/93121] std::bit_cast missing

[lyberta at lyberta dot net]

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

Lyberta  changed:

   What|Removed |Added

 CC||lyberta at lyberta dot net

--- Comment #2 from Lyberta  ---
This should block bug 88322

[Bug c++/93638] [concepts] Dependent names in requires clause reported as different types when function definition is not inline

[lyberta at lyberta dot net]

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

Lyberta  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Lyberta  ---
I have checked my codebase and found that all of my problematic cases now
compile cleanly. This bug seems to be fixed.

[Bug c++/67491] [meta-bug] concepts issues

[lyberta at lyberta dot net]

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

Bug 93638 Summary: [concepts] Dependent names in requires clause reported as 
different types when function definition is not inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93638

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c/95588] No warning in -Wformat for narrowing formats

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67479

--- Comment #2 from Eric Gallager  ---
(In reply to Nick Desaulniers from comment #1)
> In https://bugs.llvm.org/show_bug.cgi?id=41467#c4, the code owner for Clang
> seems to indicate that we could move the warnings for narrowing prints (ie.
> printing an `int` with `%hh`) to a new warning flag within the -Wformat
> group (ie. -Wformat-pedantic).

The bug for adding -Wformat-pedantic is bug 67479

> 
> I'm mostly concerned with the case where the value being printed is either
> obviously or possibly too large for the print format specifier, ex.
> 
> ```
> #include 
> #include 
> void foo(void) {
> printf("%hd\n", INT_MAX);
> }
> ```
> built with -Wformat.
> 
> I'm curious if this is indeed something GCC should warn about, and if so,
> should it be part of -Wformat? (I suspect yes for both, or would prefer it
> to be yes for both, and then to fix all instances in the Linux kernel caught
> by this, but would prefer to collaborate on this).

I think there was a separate bug for the specific case of "%hhd"/"%hd" but I
can't find it right now...

[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 #6 from Martin Sebor  ---
The priority is up to the GCC release managers but raising it won't make the
fix available before 10.2 (except on trunk).  Regardless, I should have a patch
soon.

[Bug c++/95559] GCC fails to compile "{{}}" in some versions

[haoxintu at gmail dot com]

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

--- Comment #3 from Haoxin Tu  ---
(In reply to Haoxin Tu from comment #2)
> $g++-8 test.cc ; ./a.out
> 0

Here is 

> $g++-8 bug.cc ; ./a.out
> 0

[Bug c++/95559] GCC fails to compile "{{}}" in some versions

[haoxintu at gmail dot com]

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

--- Comment #2 from Haoxin Tu  ---
(In reply to Marek Polacek from comment #1)
> I can't find a version of GCC that compiled this.  

Hi, so sorry I might use the wrong test case. Please try this case bug.cc
instead

#include 
int main(){
int a = {{}};
std::cout << a << std::endl;
return 0;
}

In godbolt https://godbolt.org/z/K_drKC .

Also, in my machine,

$g++-8 test.cc ; ./a.out
0

$g++-8 --version
g++-8 (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Copyright (C) 2018 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.

$g++-trunk bug.cc
bug.cc: In function ‘int main()’:
bug.cc:3:16: error: too many braces around scalar initializer for type ‘int’
3 | int a = {{}};
  |  

$g++-trunk --version
g++ (GCC) 11.0.0 20200526 (experimental)
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.

> I don't think this is rejects-valid.

I guess clang might have some issue in compiling "{{}}", clang accepts this
code but icc or msvc reject.

Please take a look at above situation, thanks ~

[Bug c++/95564] GCC rejects lambda expression with "noexcept(1+1)"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
There was some discussion on the Core C++ mailing list about whether a
conversion to bool should be narrowing, and though opinions differed, I think
gcc isn't incorrect in rejecting this code.

[Bug c++/95559] GCC fails to compile "{{}}" in some versions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I can't find a version of GCC that compiled this.  And clang++ emits a warning:

warning: too many braces around scalar initializer
[-Wmany-braces-around-scalar-init]

I don't think this is rejects-valid.

[Bug c++/95562] [10/11 Regression] ICE when using noexcept depending on boolean template parameter since r10-1280-g78f7607db4c53f8c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4

--- Comment #2 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 280157)
+++ gcc/fortran/decl.c  (working copy)
@@ -5924,7 +5924,7 @@ get_bind_c_idents (void)
   found_id = MATCH_YES;
   gfc_get_ha_symbol (name, &tmp_sym);
 }
-  else if (match_common_name (name) == MATCH_YES)
+  else if (gfc_match_common_name (name) == MATCH_YES)
 {
   found_id = MATCH_YES;
   com_block = gfc_get_common (name, 0);
@@ -5969,7 +5969,7 @@ get_bind_c_idents (void)
  found_id = MATCH_YES;
  gfc_get_ha_symbol (name, &tmp_sym);
}
- else if (match_common_name (name) == MATCH_YES)
+ else if (gfc_match_common_name (name) == MATCH_YES)
{
  found_id = MATCH_YES;
  com_block = gfc_get_common (name, 0);

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 280157)
+++ gcc/fortran/match.c (working copy)
@@ -5122,7 +5122,8 @@ gfc_get_common (const char *name, int from_module)

 /* Match a common block name.  */

-match match_common_name (char *name)
+match
+gfc_match_common_name (char *name)
 {
   match m;

@@ -5174,7 +5175,7 @@ gfc_match_common (void)

   for (;;)
 {
-  m = match_common_name (name);
+  m = gfc_match_common_name (name);
   if (m == MATCH_ERROR)
goto cleanup;

Index: gcc/fortran/match.h
===
--- gcc/fortran/match.h (revision 280157)
+++ gcc/fortran/match.h (working copy)
@@ -103,11 +103,8 @@ match gfc_match_call (void);

 /* We want to use this function to check for a common-block-name
that can exist in a bind statement, so removed the "static"
-   declaration of the function in match.c.
- 
-   TODO: should probably rename this now that it'll be globally seen to
-   gfc_match_common_name.  */
-match match_common_name (char *name);
+   declaration of the function in match.c.  */
+match gfc_match_common_name (char *name);

 match gfc_match_common (void);
 match gfc_match_block_data (void);
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 280157)
+++ gcc/fortran/resolve.c   (working copy)
@@ -936,9 +936,16 @@ static void
 resolve_common_vars (gfc_common_head *common_block, bool named_common)
 {
   gfc_symbol *csym = common_block->head;
+  gfc_gsymbol *gsym;

   for (; csym; csym = csym->common_next)
 {
+  gsym = gfc_find_gsymbol (gfc_gsym_root, csym->name);
+  if (gsym && gsym->type != GSYM_UNKNOWN)
+   gfc_error_now ("Global entity %qs at %L cannot appear in a "
+   "COMMON block at %L", gsym->name,
+   &gsym->where, &csym->common_block->where);
+
   /* gfc_add_in_common may have been called before, but the reported
errors
 have been ignored to continue parsing.
 We do the checks again here.  */

[Bug sanitizer/95617] [11 regression] many excess errors starting with r11-1117

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from Martin Liška  ---
I can't see that on gcc112 machine:

PASS: c-c++-common/ubsan/inline.c   -O3 -g  (test for excess errors)
PASS: c-c++-common/ubsan/inline.c   -O3 -g   scan-tree-dump-times optimized
"Function do_not_sanitize" 1
Executing on host: /home/marxin/Programming/gcc/objdir/gcc/xgcc
-B/home/marxin/Programming/gcc/objdir/gcc/
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/inline.c  
-B/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/

-B/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/

-L/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/.libs
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-Os 
-fsanitize=vla-bound -c -O3 -fdump-tree-optimized -S   -o inline.s(timeout
= 300)
spawn -ignore SIGHUP /home/marxin/Programming/gcc/objdir/gcc/xgcc
-B/home/marxin/Programming/gcc/objdir/gcc/
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/inline.c
-B/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/
-B/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/
-L/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/.libs
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -Os -fsanitize=vla-bound -c
-O3 -fdump-tree-optimized -S -o inline.s
PASS: c-c++-common/ubsan/inline.c   -Os  (test for excess errors)
PASS: c-c++-common/ubsan/inline.c   -Os   scan-tree-dump-times optimized
"Function do_not_sanitize" 1
Executing on host: /home/marxin/Programming/gcc/objdir/gcc/xgcc
-B/home/marxin/Programming/gcc/objdir/gcc/
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/inline.c  
-B/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/

-B/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/

-L/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/.libs
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-O2 -flto
-fno-use-linker-plugin -flto-partition=none  -fsanitize=vla-bound -c -O3
-fdump-tree-optimized -S   -o inline.s(timeout = 300)
spawn -ignore SIGHUP /home/marxin/Programming/gcc/objdir/gcc/xgcc
-B/home/marxin/Programming/gcc/objdir/gcc/
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/inline.c
-B/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/
-B/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/
-L/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/./libsanitizer/ubsan/.libs
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -flto
-fno-use-linker-plugin -flto-partition=none -fsanitize=vla-bound -c -O3
-fdump-tree-optimized -S -o inline.s

[Bug lto/95620] New: [10/11 Regression] relocation truncated to fit: R_X86_64_PC32 against `.bss'

[marxin at gcc dot gnu.org]

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

Bug ID: 95620
   Summary: [10/11 Regression] relocation truncated to fit:
R_X86_64_PC32 against `.bss'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

It's a test-case reduced from opa-ff project:

$ cat intel.i
double a[353783808];
int b, c, d;

int
main() {
  for (; b;)
#pragma omp parallel
a[c] = 1;
  for (;; b++)
if (a[c])
  d++;
}

$ gcc intel.i -mcmodel=medium -O2 -fopenmp
$ gcc intel.i -mcmodel=medium -O2 -flto -fopenmp
/tmp/ccaU2BEX.ltrans0.ltrans.o: in function `main':
:(.text.startup+0x2): relocation truncated to fit: R_X86_64_PC32
against `.bss'
:(.text.startup+0x22): relocation truncated to fit: R_X86_64_PC32
against `.bss'
collect2: error: ld returned 1 exit status

They have a huge .bss array (~350MB).
Since r10-5244-g6d8fd122c4f856e9 we can't handle it, the maximum value
supported by LTO is ~270MB.

[Bug c++/95609] span could have better layout

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Niall Douglas from comment #0)
> I would assume that the ABI ship has sailed, as usual

Nope.

[Bug c++/95610] bogus error: "global qualification of class name is invalid"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|GCC fails to get global |bogus error: "global
   |variable via "::" in class  |qualification of class name
   |specifier   |is invalid"
   Keywords||rejects-valid
   Last reconfirmed||2020-06-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
This has nothing to do with global variables, it's a class definition. THis
produces the same error, with no variables involved:

class s;
class ::s { };

[Bug c++/95345] Fold expressions don't work properly when pack expression has co_await

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Sandoe  ---
fixed for master and 10.2

[Bug c++/95345] Fold expressions don't work properly when pack expression has co_await

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:57ae358584f402145bad6fede8c539a225f90966

commit r10-8266-g57ae358584f402145bad6fede8c539a225f90966
Author: Iain Sandoe 
Date:   Tue Jun 9 11:44:21 2020 +0100

coroutines: Allow parameter packs in co_await/yield expressions [PR95345]

This corrects a pasto, where I copied the constraint on bare
parameter packs from the co_return to co_yield/await without
properly reviewing it.

gcc/cp/ChangeLog:

PR c++/95345
* coroutines.cc (finish_co_await_expr): Revise to allow for
parameter packs.
(finish_co_yield_expr): Likewise.

gcc/testsuite/ChangeLog:

PR c++/95345
* g++.dg/coroutines/pr95345.C: New test.

(cherry picked from commit cf7eac5805e714c7e71b699329e2c4f4a88addc1)

[Bug c++/93638] [concepts] Dependent names in requires clause reported as different types when function definition is not inline

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Hmm, I can't reproduce this with trunk or with GCC 10.1.

[Bug middle-end/95619] New: apparently in-bounds subscript in -Warray-bounds message

[msebor at gcc dot gnu.org]

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

Bug ID: 95619
   Summary: apparently in-bounds subscript in -Warray-bounds
message
   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: ---

When the type of the access is obscured by a typedef (or macro, or, in C++, by
a template parameter), -Warray-bounds warnings like the one below must be
confusing.  The warnings don't make it clear how "array subscript 2" can be 
"outside array bounds of ‘X[3]’ {aka ‘short int[3]’}".

Either the warning should also mention the type of the access, maybe in the
note, or perhaps better, the byte offset into the array (when the the types
aren't the same).

$ cat z.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout z.c
typedef short X;
typedef int Y;

void f (void*);

void g (void)
{
  X a[3];
  Y *p = (Y*)a;
  p[2] = 1;
  f (p);
}
z.c: In function ‘g’:
z.c:10:4: warning: array subscript 2 is outside array bounds of ‘X[3]’ {aka
‘short int[3]’} [-Warray-bounds]
   10 |   p[2] = 1;
  |   ~^~~
z.c:8:5: note: while referencing ‘a’
8 |   X a[3];
  | ^

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

g ()
{
  X a[3];

   [local count: 1073741824]:
  MEM[(Y *)&a + 8B] = 1;
  f (&a);
  a ={v} {CLOBBER};
  return;

}

[Bug sanitizer/95617] [11 regression] many excess errors starting with r11-1117

[seurer at linux dot vnet.ibm.com]

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

--- Comment #2 from Bill Seurer  ---
oops, thought I had included that:

wn-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-O0 -fsanitize=thread -c -O3 -fdump-tree-optimized -S -o inline.s^M
PASS: c-c++-common/tsan/inline.c   -O0  (test for excess errors)
c-c++-common/tsan/inline.c   -O0  : pattern found 0 times
FAIL: c-c++-common/tsan/inline.c   -O0   scan-tree-dump-times optimized
"Function do_not_sanitize" 1
Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++25/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++25/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/tsan/inline.c   
-fsanitize=thread -g -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never 
-fdiagnostics-urls=never  -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 
 -O2  -fsanitize=thread -c -O3 -fdump-tree-optimized  -S -o inline.s   
(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++25/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++25/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/tsan/inline.c
-fsanitize=thread -g -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-O2 -fsanitize=thread -c -O3 -fdump-tree-optimized -S -o inline.s^M
PASS: c-c++-common/tsan/inline.c   -O2  (test for excess errors)
c-c++-common/tsan/inline.c   -O2  : pattern found 0 times
FAIL: c-c++-common/tsan/inline.c   -O2   scan-tree-dump-times optimized
"Function do_not_sanitize" 1
...etc...

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/ubsan/inline.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -fsanitize=vla-bound -c -O3 -fdump-tree-optimized -S -o inline.s^M
PASS: c-c++-common/ubsan/inline.c  -std=gnu++98 (test for excess errors)
c-c++-common/ubsan/inline.c  -std=gnu++98 : pattern found 0 times
FAIL: c-c++-common/ubsan/inline.c  -std=gnu++98  scan-tree-dump-times optimized
"Function do_not_sanitize" 1
Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/ubsan/inline.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++14 -fsanitize=vla-bound -c -O3 -fdump-tree-optimized  -S -o inline.s 
  (timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/ubsan/inline.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test

[Bug c++/95618] New: [11 Regression] ICE in remap_type_1, at tree-inline.c:607

[asolokha at gmx dot com]

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

Bug ID: 95618
   Summary: [11 Regression] ICE in remap_type_1, at
tree-inline.c:607
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-11.0.0-alpha20200607 snapshot (g:f08995eefbf579acfe40f0204727d5ce388e3d0a)
ICEs when compiling the following testcase reduced from
test/SemaTemplate/instantiate-self.cpp from the clang 10.0.0 test suite:

namespace test6 {
  template constexpr T f(T);
  template constexpr T g(T t) {
typedef int arr[f(T())];
return t;
  }
  template constexpr T f(T t) {
typedef int arr[g(T())];
return t;
  }
  int n = f(0);
}

% g++-11.0.0 -c novdqht4.cpp
novdqht4.cpp: In function 'constexpr T test6::f(T) [with T = int]':
novdqht4.cpp:11:12:   in 'constexpr' expansion of 'test6::f(0)'
novdqht4.cpp:8:22:   in 'constexpr' expansion of 'test6::g(0)'
novdqht4.cpp:4:22:   in 'constexpr' expansion of 'test6::f(0)'
novdqht4.cpp:11:14: internal compiler error: in remap_type_1, at
tree-inline.c:607
   11 |   int n = f(0);
  |  ^
0x76f65b remap_type_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree-inline.c:607
0x107c420 remap_type(tree_node*, copy_body_data*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree-inline.c:736
0x107c65d remap_decl(tree_node*, copy_body_data*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree-inline.c:400
0x107f754 remap_decls
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree-inline.c:785
0x107fae9 remap_block
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree-inline.c:843
0x1082889 copy_bind_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree-inline.c:939
0x1082889 copy_tree_body_r(tree_node**, int*, void*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree-inline.c:1284
0x12cc28a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree.c:11957
0x1077830 copy_tree_body
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree-inline.c:3272
0x107d245 copy_fn(tree_node*, tree_node*&, tree_node*&)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/tree-inline.c:6625
0x8ac08b get_fundef_copy
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:1243
0x8acc08 cxx_eval_call_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:2511
0x8af6a8 cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:5701
0x8b8b45 cxx_eval_store_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:4729
0x8af5ba cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:5810
0x8af43f cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:6203
0x8aeec0 cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:6021
0x8b08f5 cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:5879
0x8afcb4 cxx_eval_statement_list
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:5271
0x8afcb4 cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200607/work/gcc-11-20200607/gcc/cp/constexpr.c:6342

[Bug middle-end/95552] [11 Regression] VLA ICE

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug sanitizer/95617] [11 regression] many excess errors starting with r11-1117

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Sorry for the breakage.
I've just pushed a fix for part of errors. Can you please paste chunk of the
log about the failing c-c++-common/ubsan/inline.c test-case?

[Bug sanitizer/95617] New: [11 regression] many excess errors starting with r11-1117

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95617
   Summary: [11 regression] many excess errors starting with
r11-1117
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

g:4089df8ef4a63126b0774c39b6638845244c20d2, r11-1117

There are a whole bunch of these excess errors plus another bunch of scan tree
errors:

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++2/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++2/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/asan/inline-kernel.c
-fsanitize=address -g
-I/home/seurer/gcc/git/gcc-test/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-O0 -fsanitize=kernel-address -c -O3 -fdump-tree-optimized -S -o
inline-kernel.s^M
cc1plus: error: '-fsanitize=address' is incompatible with
'-fsanitize=kernel-address'^M
compiler exited with status 1
FAIL: c-c++-common/asan/inline-kernel.c   -O0  (test for excess errors)
Excess errors:
cc1plus: error: '-fsanitize=address' is incompatible with
'-fsanitize=kernel-address'

> FAIL: c-c++-common/asan/inline-kernel.c   -O0  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O0  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O1  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O1  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O2  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O2  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O3 -g  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -O3 -g  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -Os  (test for excess errors)
> FAIL: c-c++-common/asan/inline-kernel.c   -Os  (test for excess errors)
> FAIL: c-c++-common/tsan/inline.c   -O0   scan-tree-dump-times optimized 
> "Function do_not_sanitize" 1
> FAIL: c-c++-common/tsan/inline.c   -O0   scan-tree-dump-times optimized 
> "Function do_not_sanitize" 1
> FAIL: c-c++-common/tsan/inline.c   -O2   scan-tree-dump-times optimized 
> "Function do_not_sanitize" 1
> FAIL: c-c++-common/tsan/inline.c   -O2   scan-tree-dump-times optimized 
> "Function do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c   -O0   scan-tree-dump-times optimized 
> "Function do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c   -O1   scan-tree-dump-times optimized 
> "Function do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c   -O2   scan-tree-dump-times optimized 
> "Function do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none   scan-tree-dump-times optimized "Function 
> do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c   -O3 -g   scan-tree-dump-times optimized 
> "Function do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c   -Os   scan-tree-dump-times optimized 
> "Function do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c  -std=gnu++14  scan-tree-dump-times 
> optimized "Function do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c  -std=gnu++17  scan-tree-dump-times 
> optimized "Function do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c  -std=gnu++2a  scan-tree-dump-times 
> optimized "Function do_not_sanitize" 1
> FAIL: c-c++-common/ubsan/inline.c  -std=gnu++98  scan-tree-dump-times 
> optimized "Function do_not_sanitize" 1

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:006f28aefeb3be575239beddc7febe56dff463a2

commit r11-1129-g006f28aefeb3be575239beddc7febe56dff463a2
Author: Iain Sandoe 
Date:   Tue Jun 9 19:17:14 2020 +0100

coroutines: Ensure distinct DTOR trees [PR95137].

Part of the PR notes that there are UBSAN fails for the coroutines
test suite.  These are primarily related to the use of the same DTOR
tree in the two edges from the await block.  Fixed by building a new
tree for each.

gcc/cp/ChangeLog:

PR c++/95137
* coroutines.cc (expand_one_await_expression): Build separate
DTOR trees for the awaitable object on the destroy and resume
paths.

[Bug middle-end/95552] [11 Regression] VLA ICE

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:77103685ff4b50b3c4d7ee76688bdf452acc82c7

commit r11-1127-g77103685ff4b50b3c4d7ee76688bdf452acc82c7
Author: Jason Merrill 
Date:   Fri Jun 5 16:36:27 2020 -0400

tree-inline: Fix VLA handling [PR95552]

The problem in this testcase comes from cloning the constructor into
complete and base variants.  When we clone the body the first time,
walk_tree_1 calls copy_tree_body_r on the type of the artificial TYPE_DECL
we made for the VLA type without calling it on the decl itself, so we
overwrite the type of the TYPE_DECL without copying the decl first.

This has been broken since we started inserting a TYPE_DECL for anonymous
VLAs in r7-457.

This patch fixes walk_tree_1 to call the function on the TYPE_DECL, as we
do
for other decls of a DECL_EXPR.

gcc/ChangeLog:

PR c++/95552
* tree.c (walk_tree_1): Call func on the TYPE_DECL of a DECL_EXPR.

gcc/testsuite/ChangeLog:

PR c++/95552
* g++.dg/ext/vla23.C: New test.

[Bug c/95588] No warning in -Wformat for narrowing formats

[ndesaulniers at google dot com]

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

--- Comment #1 from Nick Desaulniers  ---
In https://bugs.llvm.org/show_bug.cgi?id=41467#c4, the code owner for Clang
seems to indicate that we could move the warnings for narrowing prints (ie.
printing an `int` with `%hh`) to a new warning flag within the -Wformat group
(ie. -Wformat-pedantic).

I'm mostly concerned with the case where the value being printed is either
obviously or possibly too large for the print format specifier, ex.

```
#include 
#include 
void foo(void) {
printf("%hd\n", INT_MAX);
}
```
built with -Wformat.

I'm curious if this is indeed something GCC should warn about, and if so,
should it be part of -Wformat? (I suspect yes for both, or would prefer it to
be yes for both, and then to fix all instances in the Linux kernel caught by
this, but would prefer to collaborate on this).

[Bug c++/95616] [coroutines] coroutines with potentially-throwing 'co_await promise.final_suspend()' expressions should be ill-formed

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-09
   Keywords||accepts-invalid
   Target Milestone|--- |10.2
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Iain Sandoe  ---
thanks for the report

[Bug c++/95615] [coroutines] Coroutine frame and promise is leaked if exception thrown from promise.initial_suspend()

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-09
   Target Milestone|--- |10.2
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Iain Sandoe  ---
thanks for the report.

I think the get-return-object case should now be handled (once the patch to add
the cleanup is approved), since that can be covered by a conventional cleanup
expression.

Will need to look at the best way to handle the other two.

[Bug c++/95616] New: [coroutines] coroutines with potentially-throwing 'co_await promise.final_suspend()' expressions should be ill-formed

[lewissbaker.opensource at gmail dot com]

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

Bug ID: 95616
   Summary: [coroutines] coroutines with potentially-throwing
'co_await promise.final_suspend()' expressions should
be ill-formed
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lewissbaker.opensource at gmail dot com
  Target Milestone: ---

The wording of [dcl.fct.def.coroutine]/15 states:
> The expression co_­await promise.final_­suspend() shall not be 
> potentially-throwing ([except.spec]).

See http://eel.is/c++draft/dcl.fct.def.coroutine#15
and http://eel.is/c++draft/except.spec#6

I believe this means that the compiler should reject with a diagnostic any
coroutine with a promise_type where `co_await promise.final_suspend()` is not
noexcept. ie. all of the following must be declared noexcept (if they form part
of the await-expression):
- promise_type::final_suspend()
- finalSuspendObj.operator co_await()
- finalSuspendAwaiter.await_ready()
- finalSuspendAwaiter.await_suspend()
- finalSuspendAwaiter.await_resume()
- finalSuspedObj destructor
- finalSuspendAwaiter destructor

GCC (and Clang) currently accepts code that that does not declare
final_suspend() as
noexcept.

e.g. see https://godbolt.org/z/Et_5eo

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

[kargl at gcc dot gnu.org]

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

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 ---
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 280157)
+++ gcc/fortran/expr.c  (working copy)
@@ -4256,7 +4262,20 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *
   gfc_symbol *sym;
   bool target;

-  gcc_assert (rvalue->symtree);
+  if (gfc_is_size_zero_array (rvalue))
+   {
+ gfc_error ("Zero-sized array detected at %L where an entity with "
+"the TARGET attribute is expected", &rvalue->where);
+ return false;
+   }
+  else if (!rvalue->symtree)
+   {
+ gfc_error ("Pointer assignment target in initialization expression "
+"does not have the TARGET attribute at %L",
+&rvalue->where);
+ return false;
+   }
+
   sym = rvalue->symtree->n.sym;

   if (sym->ts.type == BT_CLASS && sym->attr.class_ok)

[Bug c++/95615] New: [coroutines] Coroutine frame and promise is leaked if exception thrown from promise.initial_suspend()

[lewissbaker.opensource at gmail dot com]

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

Bug ID: 95615
   Summary: [coroutines] Coroutine frame and promise is leaked if
exception thrown from promise.initial_suspend()
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lewissbaker.opensource at gmail dot com
  Target Milestone: ---

If an exception is thrown from any of the following:
- promise_type constructor
- promise.get_return_object()
- promise.initial_suspend()
- initSuspendAwaitable.await_ready()
- initSuspendAwaitable.await_suspend()

Then I believe the compiler is required to automatically
destroy the promise (if constructor completed successfully),
destroy the return return-object (if get_return_object() completed
successfully) and free the coroutine frame before letting the
exception propagate to the caller.

However, it seems that this cleanup logic is not currently
begin called by GCC in these situations.

For example, see https://godbolt.org/z/kQWjpF which shows the
behaviour when an exception is thrown from promise.initial_suspend()'s
await_suspend() method (other variants are commented out in the code).


The wording described in [dcl.fct.def.coroutine] p5 in conjunction with p11
seems to indicate that the promise object should be destroyed as the
exception propagates out of the coroutine.

[Bug c++/85270] Trivial assignment operator not considered such

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This should probably compile too:

struct S {
  S &operator=(const S &) & = default; // trivial
  S &operator=(const S &) && { return *this; } // non-trivial
};

struct R {
  S foo;
};

static_assert(__is_trivially_assignable (S &, const S &));
static_assert(__is_trivially_assignable (R &, const R &));

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/95613] ICE in main_block_label, at tree-cfg.c:1455

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/95611] ICE in access_attr_decl, at fortran/decl.c:9075

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
 CC||kargl at gcc dot gnu.org
   Last reconfirmed||2020-06-09
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 280157)
+++ gcc/fortran/decl.c  (working copy)
@@ -8998,7 +8998,7 @@ access_attr_decl (gfc_statement st)
  else
{
  gfc_error ("Access specification of the .%s. operator at %C "
-"has already been specified", sym->name);
+"has already been specified", uop->name);
  goto done;
}

[Bug fortran/95614] New: ICE in build_field, at fortran/trans-common.c:301

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

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

Bug ID: 95614
   Summary: ICE in build_field, at fortran/trans-common.c:301
   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: ---

A name clash affects versions down to at least r5 :


$ cat z1.f90
module m
common m
end


$ cat z2.f90
module m
common /xc/ m
end


$ cat z0.f90
module m
integer m
end


$ gfortran-11-20200607 -c z0.f90
z0.f90:2:9:

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


$ gfortran-11-20200607 -c z1.f90
f951: internal compiler error: Segmentation fault
0xd5a35f crash_signal
../../gcc/toplev.c:328
0x9c8ecb contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3409
0x9c8ecb size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/fold-const.c:1906
0x763a2a build_field
../../gcc/fortran/trans-common.c:301
0x763a2a create_common
../../gcc/fortran/trans-common.c:646
0x765cce translate_common
../../gcc/fortran/trans-common.c:1265
0x765e86 gfc_trans_common(gfc_namespace*)
../../gcc/fortran/trans-common.c:1356
0x778c27 gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5796
0x746891 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2238
0x6f1141 translate_all_program_units
../../gcc/fortran/parse.c:6293
0x6f1141 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x73daef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95613] New: ICE in main_block_label, at tree-cfg.c:1455

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

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

Bug ID: 95613
   Summary: ICE in main_block_label, at tree-cfg.c:1455
   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 at least r5 :


$ cat z1.f90
program p
   select case (0)
 2 end select
   goto 2
end


$ cat z2.f90
program p
   select case (0)
 2 end select
   stop
   goto 2
end


$ cat z3.f90
program p
   select case (0)
   case (2:1)
 2stop
   end select
   goto 2
end


$ cat z4.f90
program p
   select case (0)
   case (2:1)
  2 stop
   case (3)
  goto 2
   end select
end


$ gfortran-11-20200607 -c z1.f90
z1.f90:3:2:

3 |  2 end select
  |  1
4 |goto 2
  | 2
Warning: Legacy Extension: Label at (1) is not in the same block as the GOTO
statement at (2)
during GIMPLE pass: cfg
z1.f90:1:0:

1 | program p
  |
internal compiler error: Segmentation fault
0xbc593f crash_signal
../../gcc/toplev.c:328
0xbf6d3b main_block_label
../../gcc/tree-cfg.c:1455
0xbf7271 cleanup_dead_labels()
../../gcc/tree-cfg.c:1639
0xc0186b build_gimple_cfg
../../gcc/tree-cfg.c:238
0xc0186b execute_build_cfg
../../gcc/tree-cfg.c:369
0xc0186b execute
../../gcc/tree-cfg.c:405

[Bug target/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|tree-optimization   |target

--- Comment #8 from Martin Sebor  ---
Yes, the conclusion of the discussion of the patch is that the fix needs to
happen in the back end.

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

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

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

Bug ID: 95612
   Summary: [9/10/11 Regression] ICE in gfc_check_pointer_assign,
at fortran/expr.c:4274
   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, gives expected error with r6 :


$ cat z1.f90
program p
   integer, pointer :: z(:) => shape(1)
end


$ cat z2.f90
program p
   integer, pointer :: z(:) => shape([1])
end


$ gfortran-6 -c z1.f90
z1.f90:2:36:

integer, pointer :: z(:) => shape(1)
1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)


$ gfortran-11-20200607 -c z1.f90
f951: internal compiler error: in gfc_check_pointer_assign, at
fortran/expr.c:4274
0x65f27d gfc_check_pointer_assign(gfc_expr*, gfc_expr*, bool, bool)
../../gcc/fortran/expr.c:4274
0x65f48d gfc_check_assign_symbol(gfc_symbol*, gfc_component*, gfc_expr*)
../../gcc/fortran/expr.c:4438
0x63e1fe add_init_expr_to_sym
../../gcc/fortran/decl.c:1926
0x64817a variable_decl
../../gcc/fortran/decl.c:2990
0x64817a gfc_match_data_decl()
../../gcc/fortran/decl.c:6195
0x6ab513 match_word
../../gcc/fortran/parse.c:65
0x6ab513 decode_statement
../../gcc/fortran/parse.c:376
0x6acf5a next_free
../../gcc/fortran/parse.c:1279
0x6acf5a next_statement
../../gcc/fortran/parse.c:1511
0x6af304 parse_spec
../../gcc/fortran/parse.c:3738
0x6b137c parse_progunit
../../gcc/fortran/parse.c:5851
0x6b2a59 gfc_parse_file()
../../gcc/fortran/parse.c:6392
0x6feb3f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/95611] New: ICE in access_attr_decl, at fortran/decl.c:9075

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

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

Bug ID: 95611
   Summary: ICE in access_attr_decl, at fortran/decl.c:9075
   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 at least r5, with a doubled statement :


$ cat z1.f90
module m
   public operator (.a.)
   public operator (.a.)
end


$ gfortran-11-20200607 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbc593f crash_signal
 ../../gcc/toplev.c:328
0x63c87b access_attr_decl
 ../../gcc/fortran/decl.c:9075
0x6acbca decode_statement
 ../../gcc/fortran/parse.c:544
0x6acf5a next_free
 ../../gcc/fortran/parse.c:1279
0x6acf5a next_statement
 ../../gcc/fortran/parse.c:1511
0x6ae5ab parse_spec
 ../../gcc/fortran/parse.c:3922
0x6b257e parse_module
 ../../gcc/fortran/parse.c:6115
0x6b28c7 gfc_parse_file()
 ../../gcc/fortran/parse.c:6428
0x6feb3f gfc_be_parse_file
 ../../gcc/fortran/f95-lang.c:212

[Bug fortran/84245] [8/9/10/11 Regression] ICE in delete_root, at fortran/bbt.c:150

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

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

--- Comment #5 from G. Steinmetz  ---

A few more disrupted cases :

$ cat z03.f90
select type (n%&

$ cat z04.f90
select type (n%m&

$ cat z05.f90
select type (n(

$ cat z06.f90
select type (n(&

$ cat z07.f90
select type (n(m

$ cat z08.f90
select type (n(m&

$ cat z09.f90
select type (n(:

$ cat z10.f90
select type (n[&

$ cat z11.f90
select type (n[1]

$ cat z12.f90
select type (n[m

$ cat z14.f90
select type ((n

$ cat z15.f90
select type ([n

$ cat z16.f90
select type (n==


$ gfortran-11-20200607 -c z05.f90
f951: internal compiler error: Segmentation fault
0xbc593f crash_signal
 ../../gcc/toplev.c:328
0x6ef109 gfc_find_symtree(gfc_symtree*, char const*)
 ../../gcc/fortran/symbol.c:2976
0x6ef171 gfc_delete_symtree(gfc_symtree**, char const*)
 ../../gcc/fortran/symbol.c:2957
0x6f0876 gfc_restore_last_undo_checkpoint()
 ../../gcc/fortran/symbol.c:3698
0x6a8157 reject_statement
 ../../gcc/fortran/parse.c:2633
0x6ab744 match_word
 ../../gcc/fortran/parse.c:70
0x6ab744 decode_statement
 ../../gcc/fortran/parse.c:428
0x6acf5a next_free
 ../../gcc/fortran/parse.c:1279
0x6acf5a next_statement
 ../../gcc/fortran/parse.c:1511
0x6b2708 gfc_parse_file()
 ../../gcc/fortran/parse.c:6375
0x6feb3f gfc_be_parse_file
 ../../gcc/fortran/f95-lang.c:212

[Bug c++/95610] New: GCC fails to get global variable via "::" in class specifier

[haoxintu at gmail dot com]

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

Bug ID: 95610
   Summary: GCC fails to get global variable via "::" in class
specifier
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This case test.cc

class s;
class ::s { } ss;

$g++ -c test.cc
test.cc:2:11: error: global qualification of class name is invalid before ‘{’
token
2 | class ::s {int a;} ss;
  | 

GCC fails to compile this c++ code, replacing "class" with "struct" or "union"
also reproduces above result.

Also, if test.cc removes "::", GCC compiles it well. 

I also tested test.cc in clang, icc, or msvc, and they compile it successfully.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #4 from Jeffrey A. Law  ---
FWIW, I bootstrapped m68k within qemu on May30 with no testsuite regressions. 
Jun 6 also bootstrapped, but with some regressions with -fprofile-generate.

So clearly you're builds are doing something different than mine.

What Richi is asking for is a backtrace from the compiler itself.  Without that
or some way to reproduce the problem, then there's not much we can do.

[Bug tree-optimization/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Bill Seurer from comment #6)
> I tried the patch and it allowed me to build gcc on a power7 system.

but AFAIU the discussion - the builtin has the wrong signature (and needs to be
fixed)?
or did I misunderstand?

[Bug fortran/94377] Won't compile when deallocating a parameterized derived type

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #5 from Dominique d'Humieres  ---
I only get errors for both tests (from GCC8 up to master).

[Bug tree-optimization/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[seurer at linux dot vnet.ibm.com]

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

--- Comment #6 from Bill Seurer  ---
I tried the patch and it allowed me to build gcc on a power7 system.

[Bug c++/95609] New: span could have better layout

[s_gccbugzilla at nedprod dot com]

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

Bug ID: 95609
   Summary: span could have better layout
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s_gccbugzilla at nedprod dot com
  Target Milestone: ---

I would assume that the ABI ship has sailed, as usual, but if libstdc++'s
span could instead have the layout:

{
  T *p;
  size_t l;
}

... then a span would be layout-compatible with struct iovec, which would
save libstdc++ having to reimplement span<> with a struct iovec compatible
layout for any future std::file_handle::buffer_type, if that gets standardised.

I put notice of this out onto lib-ext last year requesting this of span
implementations. libc++ heeded my request, MSVC have very kindly undone their
initial implementation to meet the pointer + size layout plus add standard
layout, so they'll be on that too going forth.

In the end, this request is about as unimportant for right now as you can get.
It's purely for saving you, Jonathan, avoidable work later on.

Niall

[Bug middle-end/95552] [11 Regression] VLA ICE

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1122-gef41587df9839d1dfc77dbc48a0830e42b36626e
Author: Jason Merrill 
Date:   Sat Jun 6 00:07:21 2020 -0400

c++: Tweak predeclare_vla.

We only need to predeclare a VLA type if it's wrapped in a pointer type;
otherwise gimplify_type_sizes will handle it.

gcc/cp/ChangeLog:

PR c++/95552
* cp-gimplify.c (predeclare_vla): Only predeclare a VLA if it's
wrapped in a pointer type.

[Bug c++/95608] New: c++20 wrong code for defaulted equality comparison on array member variables

[vermaelen.wouter at gmail dot com]

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

Bug ID: 95608
   Summary: c++20 wrong code for defaulted equality comparison on
array member variables
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vermaelen.wouter at gmail dot com
  Target Milestone: ---

The generated code does not actually compare the content of the array. It does
with clang and msvc.

-

https://godbolt.org/z/VkuVXj

-

struct S {
int a[5];
bool operator==(const S&) const = default;
};

bool f(const S& x, const S& y) {
return x == y;
}

-

[Bug c++/95607] New: Inconsistent treating of default argument instantiation as immediate context

[akrzemi1 at gmail dot com]

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

Bug ID: 95607
   Summary: Inconsistent treating of default argument
instantiation as immediate context
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

Consider the following three declarations in exactly this order:

```
template int f(T, T = "") ;
int f(...) ;

template
concept has_f = requires (T v) { f(v); };
```

If I evaluate expression `has_f` it returns `false`. This is quite
surprising because other compilers, like Clang give me a hard error because in
order to test the satisfaction of the concept it has to perform *default
argument instantiation*. But we could call it "implementation divergence".
Anyway, GCC apparently considers the default argument instantiation to be *in*
immediate context. 

But when I make the call `f(1)` I get a hard error. The first overload cannot
work because the default argument cannot be instantiated. The second one would
wort, but it is not even considered. So it looks like in this case GCC treats
default argument instantiation as *not being in* immediate context. 

This is two different behaviors in two different contexts. It is confusing, and
difficult to build a mental model that would help anticipate when we get a hard
error and when we get a SFINAE-detectable one.

[Bug c++/95599] [coroutines] destructor for temporary operand to co_yield expression called before end of full-expression

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
(In reply to Lewis Baker from comment #3)

> Also, I'm not sure why GCC is evaluating the second operand to operator,()
> first and why it is constructing resource{1} _after_ the coroutine has
> suspended. Nothing should happen in the coroutine body between
> await_suspend() and await_resume().

two problems - correctling the lifetime of awaitables I have already fixed
locally (not ready to post yet, but).  The second, handling of operator, needs
a bit more.

[Bug c++/95599] [coroutines] destructor for temporary operand to co_yield expression called before end of full-expression

[lewissbaker.opensource at gmail dot com]

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

--- Comment #3 from Lewis Baker  ---
I don't think that whether or not the awaitables or operands to co_yield are
captured by reference / aliased should play into the sequencing of calls to the
destructor.

The destructors of temporaries should always be sequenced to occur at the
semicolon, which will always happen after the coroutine resumes.

For another clearer example, see https://godbolt.org/z/tKQVnb

e.g. changing the example 

--
struct resource {
int x;
resource(int x) : x(x) { std::printf("resource(%i)\n", x); }
~resource() { std::printf("~resource(%i)\n", x); }
resource(resource&&) = delete;
};

generator f() {
(resource{1}, co_yield resource{2});
}
--

Here we are creating temporaries and sequencing expressions using operator,().

The destructor of both resource{1} and resource{2} should both occur at the
semicolon, after the coroutine suspends and resumes, regardless of whether the
object is captured by reference in an awaitable.

ie. the expected output of the modified program should be (this is what clang
does):
```
resource(1)
resource(2)
awaitable::await_suspend()
awaitable::await_resume()
~resource(2)
~resource(1)
```

But the observed output with GCC is:
```
resource(2)
awaitable::await_suspend()
resource(1)
awaitable::await_resume()
~resource(1)
```

Also, I'm not sure why GCC is evaluating the second operand to operator,()
first and why it is constructing resource{1} _after_ the coroutine has
suspended. Nothing should happen in the coroutine body between await_suspend()
and await_resume().

[Bug target/95469] [11 regression] several vperm test case failures after r11-736 on power 9 (only)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Should be fixed now.

[Bug c++/95567] Defaulted virtual <=> has the wrong behavior

[barry.revzin at gmail dot com]

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

--- Comment #1 from Barry Revzin  ---
To follow up on this, it's not the operator<=> being virtual that's significant
but rather the class itself being polymorphic. This exhibits the same behavior:

#include 

struct B {
  B(int i) : i(i) {}
  VIRTUAL ~B() = default;

  std::strong_ordering operator<=>(B const& other) const = default;
  int i;
};

struct D : B {
  D(int i, int j) : B(i), j(j) {}
  int j;
};

bool check() {
return B(2) == D(2, 3);
}

https://godbolt.org/z/ZFqB59

[Bug fortran/95215] [OMP] internal compiler error: in gimplify_expr, at gimplify.c:14079

[john.donners at atos dot net]

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

--- Comment #2 from John Donners  ---
thanks for reviewing this. Indeed, the compiler bug does not occur when using
the intelmicemul target:

gfortran -foffload=x86_64-intelmicemul-linux-gnu -g  -fopenmp -O3 bla.f90
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/tmp/ccfY1ov8.o: In function `therm_ice_':
/home_nfs_robin_ib/bdonnersj/tmp/bla.f90:61: undefined reference to `budget_'
/home_nfs_robin_ib/bdonnersj/tmp/bla.f90:61: undefined reference to `budget_'
collect2: error: ld returned 1 exit status

but it does occur for the nvptx-none target:

$ gfortran -foffload=nvptx-none -g  -fopenmp -O3 bla.f90
during GIMPLE pass: ompdevlow
bla.f90: In function ‘thermodynamics_._omp_fn.1’:
bla.f90:45: internal compiler error: in gimplify_expr, at gimplify.c:14079
   45 |  call therm_ice
  | 
0x7727cf gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:14079
0x77deab gimple_regimplify_operands(gimple*, gimple_stmt_iterator*)
../../gcc/gcc/gimplify-me.c:247
0x89fb57 execute_omp_device_lower
../../gcc/gcc/omp-offload.c:1975
0x89fb57 execute
../../gcc/gcc/omp-offload.c:2011
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1
exit status
compilation terminated.
lto-wrapper: fatal error:
/software/compilers/gcc-offload/10.1.0/gnu-9.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.1.0//accel/nvptx-none/mkoffload
returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

I do not know what happens for the amdgcn-amdhsa target.

[Bug target/95347] rs6000 mcpu=future generating stfs instead of pstfs for pc-relative references

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from acsawdey at gcc dot gnu.org ---
This is fixed now.

[Bug fortran/95138] ICE on transfer to unlimited polymorphic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed|2020-05-14 00:00:00 |2020-06-09

--- Comment #3 from Dominique d'Humieres  ---
Confirmed from GGC7 up to master.

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[kuzniar95 at o2 dot pl]

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

kuzniar95 at o2 dot pl changed:

   What|Removed |Added

 CC||kuzniar95 at o2 dot pl

--- Comment #15 from kuzniar95 at o2 dot pl ---
The related patch is a reason for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606. May I kindly ask you to
look into that?

[Bug fortran/95215] [OMP] internal compiler error: in gimplify_expr, at gimplify.c:14079

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-06-09
   Priority|P3  |P4
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME since GCC6 up to master.

[Bug debug/94235] worse debug info with O0 than with O2 with flto

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
--- lto-cgraph.c.jj 2020-06-09 08:28:11.221207787 +0200
+++ lto-cgraph.c2020-06-09 16:02:20.251542204 +0200
@@ -290,6 +290,7 @@ lto_output_edge (struct lto_simple_outpu
   bp_pack_value (&bp, edge->indirect_info->num_speculative_call_targets,
 16);
 }
+  stream_output_location (ob, &bp, edge->goto_locus);
   streamer_write_bitpack (&bp);
 }

@@ -1511,6 +1512,7 @@ input_edge (class lto_input_block *ib, v
   edge->indirect_info->num_speculative_call_targets
= bp_unpack_value (&bp, 16);
 }
+  stream_input_location (&edge->goto_locus, &bp, ZZZ);
 }


is clearly not it because one needs data_in which isn't available, and do
something about locus caching etc.

[Bug c++/95606] New: [10/11 regression] conflicts with std::is_constructible

[kuzniar95 at o2 dot pl]

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

Bug ID: 95606
   Summary: [10/11 regression]  conflicts with
std::is_constructible
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kuzniar95 at o2 dot pl
  Target Milestone: ---

Created attachment 48713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48713&action=edit
main.ii + verbose gcc invoke command

Hi! I'm coming from nlohmann/json project on GitHub where we detected a
possible regression in GCC 10 and later.

Please follow this link for details:
https://github.com/nlohmann/json/issues/2129 You will find minimal code example
there with some detailed analysis of "compilation path" but I need your help
whether it actually is a regression or not. For example, I'm not sure if the
compiler should jump from decltype(swap(std::declval<_Tp&>(),
std::declval<_Tp&>())) with some implicit conversions to std::any constructor
(maybe it should be inaccessible) as clang seems to dismiss std::any which I
discovered by poisoning std::any constructor. I'm also attaching some files as
requested by "bug reporting instructions".

Even if you think GCC works fine, maybe it could be improved so it gives better
error messages in the future in such convoluted scenarios. Please let me know
what you think.

P.S. I've taken a while to bisect and build GCC compilers and I discovered this
was the first broken commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=608a080c3f6e5a8338ff99658b27e226cbba7a67

[Bug tree-optimization/95056] [11 Regression] slp-perm-9.c fails on aarch64 after gbc484e250990393e887f7239157cc85ce6fadcce

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug debug/94235] worse debug info with O0 than with O2 with flto

[palves at redhat dot com]

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

Pedro Alves  changed:

   What|Removed |Added

 CC||palves at redhat dot com

--- Comment #2 from Pedro Alves  ---
Should Bug 47819 still be used to track debug info + lto bugs?

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
gcc/cp/typeck.c does:

  if (cxx_dialect >= cxx11)
pedwarn (loc, OPT_Wwrite_strings,
 "ISO C++ forbids converting a string constant to %qT",
 totype);
  else
warning_at (loc, OPT_Wwrite_strings,
"deprecated conversion from string constant to %qT",
totype);

As the example above shows, allowing the conversion and then conditionally
warning about it is not conforming.

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Confirmed. Even with -std=c++14 -pedantic-errors we still choose the wrong
overload (and then give an error that the conversion is not allowed).

There seems to be no way to disable the conversion from string literals to
char* that has been deprecated for years.

[Bug c++/93979] missing context in error message due to inheriting template constructor

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-09
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Confirmed.

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

[gcc at pkh dot me]

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

--- Comment #5 from gcc at pkh dot me ---
I'd like to point out that this regression impacts badly a production app.
We're using this pattern to compare an input vector of floats to a vector of
zeros, but the comparison always returns 0 now, which basically breaks
everything. We do have a workaround (removing the "= {0}"), but I don't think
this is an isolate case.

Maybe the priority could be raised?

[Bug tree-optimization/95056] [11 Regression] slp-perm-9.c fails on aarch64 after gbc484e250990393e887f7239157cc85ce6fadcce

[acoplan at gcc dot gnu.org]

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #2 from Alex Coplan  ---
I've reproduced this failure on arm-none-eabi, aarch64-none-elf, and
aarch64-linux-gnu.

I believe this was introduced in bc484e250990393e887f7239157cc85ce6fadcce.

[Bug c++/95562] [10/11 Regression] ICE when using noexcept depending on boolean template parameter since r10-1280-g78f7607db4c53f8c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/95154] [11 regression] FAIL: g++.dg/abi/pure-virtual1.C -std=c++14 (test for excess errors)

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|ia64-*-*,*-*-darwin*|ia64-*-*
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Andreas Schwab  ---
Fixed.

[Bug c++/95560] [8/9/10/11 Regression] ICE in comptypes, at cp/typeck.c:1498 since r10-4254-ge0d91792eec490d1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[8/9/10/11 Regression] ICE
   |comptypes, at   |in comptypes, at
   |cp/typeck.c:1498 since  |cp/typeck.c:1498 since
   |r10-4254-ge0d91792eec490d1  |r10-4254-ge0d91792eec490d1

--- Comment #5 from Martin Liška  ---
You are right, with:
g++ pr95560.ii -std=c++17 -c -Wshadow=compatible-local

it started with r7-4206-g84ff4775d41b716c.

[Bug lto/95605] LTO and object files generated by dtrace -G

[doko at debian dot org]

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

--- Comment #3 from Matthias Klose  ---
dtrace -G calls gcc to generate the .o file, and you can use the CC and CFLAGS
environment vars to inject the options you need.  Ugly, but you can avoid that
by passing the appropriate options.

[Bug lto/95605] LTO and object files generated by dtrace -G

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #2 from Richard Biener  ---
non-LTO objects are not taken into account here so I belive this isn't the
reason you are not seeing the CF protection enabled.

[Bug testsuite/81058] FAIL: gcc.target/i386/avx512bw-vpmovu?swb-1.c scan-assembler-times vpmovu?swb.*

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #12 from Iain Sandoe  ---
fixed on open branches

[Bug c++/95560] [10/11 Regression] ICE in comptypes, at cp/typeck.c:1498 since r10-4254-ge0d91792eec490d1

[edlinger at gcc dot gnu.org]

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

--- Comment #4 from Bernd Edlinger  ---
don't know if it helps, but with -Wshadow=compatible-local
the regression begins probably earlier.

[Bug lto/95604] LTO doesn't pick up -fcf-protection flag for the link step

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Matthias Klose from comment #2)
> Really? The documentation states:
> 
>   The macro "__CET__" is defined when -fcf-protection is used.
> 
> so it's a preprocessor option as well?

__CET__ check isn't needed to enable CET in C/C++.  __CET__ is needed to
add CET support to assembly codes.  If there are mixed source codes,
-fcf-protection should be used for compilation.

[Bug lto/95604] LTO doesn't pick up -fcf-protection flag for the link step

[doko at debian dot org]

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

--- Comment #2 from Matthias Klose  ---
Really? The documentation states:

  The macro "__CET__" is defined when -fcf-protection is used.

so it's a preprocessor option as well?

[Bug lto/95605] LTO and object files generated by dtrace -G

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-06-09

--- Comment #1 from Martin Liška  ---
dtrace is new for me, can you please explain more how it works and what's
expected output?

[Bug lto/95604] LTO doesn't pick up -fcf-protection flag for the link step

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
(In reply to Matthias Klose from comment #0)
> Building the example from PR93966 with the -fcf-protection flag in the
> compile step, but not in the link step, I get the error triggered by the -z
> option.
> 
> $ cat x.c 
> #include 
> 
> int
> main ()
> {
>   printf ("hello\n");
>   return 0;
> }
> 
> $ gcc-10 -flto -fcf-protection -c x.c
> $ gcc-10 -flto x.o -Wl,-z,cet-report=error
> /usr/bin/ld: /tmp/ccM08n28.ltrans0.ltrans.o: error: missing IBT and SHSTK
> properties
> collect2: error: ld returned 1 exit status
> 
> Isn't the lto link step supposed to pick up the compilation options from the
> compile step?
> 
> An objdump -w -s --section=.gnu.lto_.opts x.o
> shows that this option is recorded, however I don't see it printed out in
> the link step, even when calling gcc with -v.
> 
> An unrelated question: why is the compile step from PR93966 not called with
> -fcf-protection?

-fcf-protection is a codegen option. I think -flto -fcf-protection at
the final link is sufficient to enable CET.

[Bug lto/95605] New: LTO and object files generated by dtrace -G

[doko at debian dot org]

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

Bug ID: 95605
   Summary: LTO and object files generated by dtrace -G
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

An object file generated with dtrace -G doesn't have a .gnu.lto_.opts section.
Afaiu the lto linking is supposed to merge all flags used for all compile steps
into the link step, if the flag was used for all .o files.  That results in a
binary built without any options, if these are not present in the link step.

[Bug lto/95604] New: LTO doesn't pick up -fcf-protection flag for the link step

[doko at debian dot org]

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

Bug ID: 95604
   Summary: LTO doesn't pick up -fcf-protection flag for the link
step
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Building the example from PR93966 with the -fcf-protection flag in the compile
step, but not in the link step, I get the error triggered by the -z option.

$ cat x.c 
#include 

int
main ()
{
  printf ("hello\n");
  return 0;
}

$ gcc-10 -flto -fcf-protection -c x.c
$ gcc-10 -flto x.o -Wl,-z,cet-report=error
/usr/bin/ld: /tmp/ccM08n28.ltrans0.ltrans.o: error: missing IBT and SHSTK
properties
collect2: error: ld returned 1 exit status

Isn't the lto link step supposed to pick up the compilation options from the
compile step?

An objdump -w -s --section=.gnu.lto_.opts x.o
shows that this option is recorded, however I don't see it printed out in the
link step, even when calling gcc with -v.

An unrelated question: why is the compile step from PR93966 not called with
-fcf-protection?

[Bug c++/95560] [10/11 Regression] ICE in comptypes, at cp/typeck.c:1498 since r10-4254-ge0d91792eec490d1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Host|x86_64-w64-mingw32  |
 Ever confirmed|0   |1
 CC||edlinger at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2020-06-09
  Build|x86_64-w64-mingw32  |
Summary|internal compiler error:|[10/11 Regression] ICE in
   |Segmentation fault  |comptypes, at
   ||cp/typeck.c:1498 since
   ||r10-4254-ge0d91792eec490d1
 Status|UNCONFIRMED |NEW
 Target|x86_64-w64-mingw32  |

--- Comment #3 from Martin Liška  ---
Confirmed, started with r10-4254-ge0d91792eec490d1.

Reduced test-case:

$ cat pr95560.ii
template  void fn1() {
  bool ready;
  enum class State { ready };
}

$ g++ -c -std=c++2a pr95560.ii
pr95560.ii: In function ‘void fn1()’:
pr95560.ii:3:22: internal compiler error: in comptypes, at cp/typeck.c:1498
3 |   enum class State { ready };
  |  ^
0x6be442 comptypes(tree_node*, tree_node*, int)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:1498
0x9ab7ea check_local_shadow
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:2765
0x9ab7ea do_pushdecl
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:3112
0x9ac140 pushdecl(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:3177
0x93c722 build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
/home/marxin/Programming/gcc/gcc/cp/decl.c:15922
0x9cd7a7 cp_parser_enumerator_definition
/home/marxin/Programming/gcc/gcc/cp/parser.c:19544
0x9cd7a7 cp_parser_enumerator_list
/home/marxin/Programming/gcc/gcc/cp/parser.c:19473
0x9cd7a7 cp_parser_enum_specifier
/home/marxin/Programming/gcc/gcc/cp/parser.c:19404
0x9cd7a7 cp_parser_type_specifier
/home/marxin/Programming/gcc/gcc/cp/parser.c:17734
0x9cdd62 cp_parser_decl_specifier_seq
/home/marxin/Programming/gcc/gcc/cp/parser.c:14410
0x9ce941 cp_parser_simple_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:13664
0x9d07ea cp_parser_declaration_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:13217
0x9d146a cp_parser_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:11523
0x9d2398 cp_parser_statement_seq_opt
/home/marxin/Programming/gcc/gcc/cp/parser.c:11889
0x9d2478 cp_parser_compound_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:11839
0x9e9a65 cp_parser_function_body
/home/marxin/Programming/gcc/gcc/cp/parser.c:23110
0x9e9a65 cp_parser_ctor_initializer_opt_and_function_body
/home/marxin/Programming/gcc/gcc/cp/parser.c:23161
0x9ecd9d cp_parser_function_definition_after_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:29057
0x9edd89 cp_parser_function_definition_from_specifiers_and_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:28973
0x9edd89 cp_parser_init_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:20721
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/95603] [11 Regression] sanitizer_linux.cpp:1880:16: error: missing terminating ' character

[zsojka at seznam dot cz]

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

--- Comment #3 from Zdenek Sojka  ---
Thanks, all the rounds with asking at gcc-help, waiting for reply, and even
recompiling this morning took too much time.

[Bug sanitizer/95603] [11 Regression] sanitizer_linux.cpp:1880:16: error: missing terminating ' character

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Martin Liška  ---
Yes, it should be fixed.

[Bug sanitizer/95603] [11 Regression] sanitizer_linux.cpp:1880:16: error: missing terminating ' character

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Didn't r11-1083-g942a384ef9f38777df25b2bfa421ce6a07553a98 fix this?

[Bug fortran/95501] ICE in gfc_match_pointer_assignment, at fortran/match.c:1422

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started to ICE with r9-3803-ga5fbc2f36a291cbe.

[Bug fortran/95502] ICE in gfc_check_do_variable, at fortran/parse.c:4446

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started to ICE with r9-3803-ga5fbc2f36a291cbe.

[Bug sanitizer/95603] New: [11 Regression] sanitizer_linux.cpp:1880:16: error: missing terminating ' character

[zsojka at seznam dot cz]

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

Bug ID: 95603
   Summary: [11 Regression] sanitizer_linux.cpp:1880:16: error:
missing terminating ' character
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

As originally reported in the thread [1], libsanitizer fails to build on
x86_64-pc-linux-gnu to riscv64-unknown-linux-gnu cross-compiler 
configured as:

/repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-
annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --
with-ppl --with-isl --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x
86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux
-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/
riscv64-unknown-linux-gnu-as --disable-multilib --disable-libstdcxx-pch --
prefix=/repo/gcc-trunk//binary-trunk-r11-767-20200601155732-gff7da2b5d62-
checking-yes-rtl-df-extra-riscv64

this is probably since [2]. The code would be probably accepted with
-std=gnu++14 or by patching the code not to contain the binary constants.

The error is:

libtool: compile:  /repo/build-gcc-trunk-riscv64/./gcc/xgcc -shared-libgcc
-B/repo/build-gcc-trunk-riscv64/./gcc -nostdinc++
-L/repo/build-gcc-trunk-riscv64/riscv64-unknown-linux-gnu/libstdc++-v3/src
-L/repo/build-gcc-trunk-riscv64/riscv64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/repo/build-gcc-trunk-riscv64/riscv64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/repo/gcc-trunk//binary-trunk-r11-1081-20200609083936-gd6dbb71e468-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/bin/
-B/repo/gcc-trunk//binary-trunk-r11-1081-20200609083936-gd6dbb71e468-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/lib/
-isystem
/repo/gcc-trunk//binary-trunk-r11-1081-20200609083936-gd6dbb71e468-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/include
-isystem
/repo/gcc-trunk//binary-trunk-r11-1081-20200609083936-gd6dbb71e468-checking-yes-rtl-df-extra-riscv64/riscv64-unknown-linux-gnu/sys-include
-D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I/repo/gcc-trunk/libsanitizer/sanitizer_common -I.. -I
/repo/gcc-trunk/libsanitizer/include -I /repo/gcc-trunk/libsanitizer -isystem
/repo/gcc-trunk/libsanitizer/include/system -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/riscv64-unknown-linux-gnu
-I/repo/gcc-trunk/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
/repo/gcc-trunk/libsanitizer/../libbacktrace -I ../libbacktrace -I
/repo/gcc-trunk/libsanitizer/../include -include
/repo/gcc-trunk/libsanitizer/libbacktrace/backtrace-rename.h -g -O2
-D_GNU_SOURCE -MT sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo -c
/repo/gcc-trunk/libsanitizer/sanitizer_common/sanitizer_linux.cpp  -fPIC -DPIC
-o .libs/sanitizer_linux.o
/repo/gcc-trunk/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1880:12:
warning: binary constants are a C++14 feature or GCC extension
 1880 |   case 0b10'010:  // c.lwsp (rd != x0)
  |^~~~
/repo/gcc-trunk/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1880:16:
warning: missing terminating ' character
 1880 |   case 0b10'010:  // c.lwsp (rd != x0)
  |^
/repo/gcc-trunk/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1880:16:
error: missing terminating ' character
 1880 |   case 0b10'010:  // c.lwsp (rd != x0)
  |^~~



[1] https://gcc.gnu.org/pipermail/gcc-help/2020-June/139023.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547010.html

[Bug c++/95562] [10/11 Regression] ICE when using noexcept depending on boolean template parameter since r10-1280-g78f7607db4c53f8c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||9.3.0
  Known to fail||10.1.0, 11.0
 Status|UNCONFIRMED |NEW
Summary|ICE when using noexcept |[10/11 Regression] ICE when
   |depending on boolean|using noexcept depending on
   |template parameter  |boolean template parameter
   ||since
   ||r10-1280-g78f7607db4c53f8c
   Last reconfirmed||2020-06-09
 CC||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/95569] ICE in tmmark：verify_ssa failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug tree-optimization/95570] ICE: Segmentation fault in vect_loop_versioning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> Yeah, that was for vector components.  Not that I like it much.  Can
> the middle-end assume that the Ada boolean types only contain 0 or 1
> or are there other values that are supposed to be well-defined
> true or false values?

The only well-defined values are 0 and 1, but all the bits up to the precision
need to be preserved in "nonlogical contexts".  So it's a standard boolean type
in "logical contexts" (with binary logic) and an integral type with precision 8
in "nonlogical contexts", the possibly issues arising of course at the
transition.

In practice this works fine without special handling in almost all cases, you
just need to be careful when you're manipulating bit patterns.

[Bug target/95602] [10/11 Regression] Wrong code w/ -O0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Liška  ---
It's an invalid code:

$ gcc pr95602.c -fsanitize=address && ./a.out 
pr95602.c:9:16: warning: initialization of ‘__int128 *’ from incompatible
pointer type ‘int *’ [-Wincompatible-pointer-types]
9 | __int128 *mc = &tq.oj;
  |^
=
==25529==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00404264 at pc 0x004013f3 bp 0x7fffe070 sp 0x7fffe068
READ of size 16 at 0x00404264 thread T0
#0 0x4013f2 in r8 (/home/marxin/Programming/testcases/a.out+0x4013f2)
#1 0x4015ee in main (/home/marxin/Programming/testcases/a.out+0x4015ee)
#2 0x7741acc9 in __libc_start_main ../csu/libc-start.c:308
#3 0x4010c9 in _start (/home/marxin/Programming/testcases/a.out+0x4010c9)

0x00404268 is located 0 bytes to the right of global variable 'tq' defined
in 'pr95602.c:6:11' (0x404260) of size 8
0x00404264 is located 60 bytes to the left of global variable 'sn' defined
in 'pr95602.c:7:5' (0x4042a0) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow
(/home/marxin/Programming/testcases/a.out+0x4013f2) in r8
Shadow bytes around the buggy address:
  0x800787f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078810: 00 00 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x80078820: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9
  0x80078830: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
=>0x80078840: f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00[00]f9 f9 f9
  0x80078850: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc
==25529==ABORTING

$ gcc pr95602.c -fsanitize=undefined && ./a.out 
pr95602.c:9:16: warning: initialization of ‘__int128 *’ from incompatible
pointer type ‘int *’ [-Wincompatible-pointer-types]
9 | __int128 *mc = &tq.oj;
  |^
pr95602.c:36:12: runtime error: load of misaligned address 0x00404104 for
type '__int128', which requires 16 byte alignment
0x00404104: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00
  ^ 
Segmentation fault (core dumped)