[Bug c++/96107] New: [11 regression] ICE on invalid c++: "Error reporting routines re-entered." when using -Wall

[slyfox at inbox dot ru]

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

Bug ID: 96107
   Summary: [11 regression] ICE on invalid c++: "Error reporting
routines re-entered." when using -Wall
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

$ cat bug.cc

struct a {
  using b = a;
  class c f(, b , (c *, *{ int d;
  b e;
  f(d, e, [](auto, *))


Internal compiler error: Error reporting routines re-entered.
0x7aa464 check_nonnull_arg
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/c-family/c-common.c:5523
0x7aa464 check_nonnull_arg
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/c-family/c-common.c:5498
0x7d12c6 check_function_nonnull
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/c-family/c-common.c:5315
0x7d12c6 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/c-family/c-common.c:5764
0x624e9b build_over_call
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/call.c:8868
0x626cc4 build_new_method_call_1
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/call.c:10348
0x6276bf build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/call.c:10423
0x7423e5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/pt.c:20042
0x7437ff tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/pt.c:15913
0x7437ff tsubst(tree_node*, tree_node*, int, tree_node*)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/pt.c:15913
0x6a56e5 dump_template_bindings
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:416
0x6a5907 dump_substitution
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:1562
0x6a5907 dump_substitution
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:1550
0x6a0b0c dump_function_decl
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:1720
0x6a6998 decl_to_string
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:3101
0x6a6998 cp_printer
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/cp/error.c:4261
0x15b8bbe pp_format(pretty_printer*, text_info*)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/pretty-print.c:1475
0x15ace42 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/diagnostic.c:1159
0x15af5fd diagnostic_impl
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/diagnostic.c:1309
0x15af5fd inform(unsigned int, char const*, ...)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/diagnostic.c:1388

For comparison gcc-10.1.0 does not crash:

$ /usr/bin/x86_64-pc-linux-gnu-g++-10.1.0 -o bug.o -c -Wall   bug.cc

[Bug c++/96107] [11 regression] ICE on invalid c++: "Error reporting routines re-entered." when using -Wall

[slyfox at inbox dot ru]

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

--- Comment #1 from Sergei Trofimovich  ---
Forgot to post actual command. It's the same as for 10.1.0:

$ LANG=C /usr/bin/x86_64-pc-linux-gnu-g++ -o bug.o -c -Wall   bug.cc

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

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Btw. one can debug that with the current releases/gcc-10 branch locally in
order to get proper locations.
Thanks Jakub for the analysis.

[Bug testsuite/96098] [11 regression] gcc.dg/vect/bb-slp-pr68892.c fails since r11-205

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
The testcase probably needs to move to costmodel/*/ because it's outcome now
depends on the actual costing.  On x86_64:

0x54db890 _1 2 times vector_store costs 24 in body
0x54db890  1 times vec_construct costs 8 in prologue
0x54db890  1 times vec_construct costs 8 in prologue
0x54dcba0 _1 1 times scalar_store costs 12 in body
0x54dcba0 _2 1 times scalar_store costs 12 in body
0x54dcba0 _3 1 times scalar_store costs 12 in body
0x54dcba0 _4 1 times scalar_store costs 12 in body

while ppc64le has

0x42edf00 _1 2 times vector_store costs 2 in body
0x42edf00  1 times vec_construct costs 2 in prologue
0x42edf00  1 times vec_construct costs 2 in prologue
0x42ef850 _1 1 times scalar_store costs 1 in body
0x42ef850 _2 1 times scalar_store costs 1 in body
0x42ef850 _3 1 times scalar_store costs 1 in body
0x42ef850 _4 1 times scalar_store costs 1 in body

so for ppc64le it's 6 vector vs. 4 scalar while on x86_64 it's 36 vector
vs. 48 scalar.  As the comment in the testcase explains the vectorization
is considered a "bug" (well, I'd say if write-combining is profitable
we should of course do it):

/* ???  Due to the gaps we fall back to scalar loads which makes the
   vectorization profitable.  */
/* { dg-final { scan-tree-dump "not profitable" "slp2" { xfail *-*-* } } } */
/* { dg-final { scan-tree-dump-times "BB vectorization with gaps at the end of
a load is not supported" 1 "slp2" } } */
/* { dg-final { scan-tree-dump-times "Basic block will be vectorized" 1 "slp2"
} } */

on x86_64 we get

movsd   a+2048(%rip), %xmm0
movsd   a(%rip), %xmm1
movhpd  a+3072(%rip), %xmm0
movhpd  a+1024(%rip), %xmm1
movaps  %xmm1, b(%rip)
movaps  %xmm0, b+16(%rip)

vs.

movsd   a(%rip), %xmm0
movsd   %xmm0, b(%rip)
movsd   a+1024(%rip), %xmm0
movsd   %xmm0, b+8(%rip)
movsd   a+2048(%rip), %xmm0
movsd   %xmm0, b+16(%rip)
movsd   a+3072(%rip), %xmm0
movsd   %xmm0, b+24(%rip)

where it looks profitable (larger stores are also always good for STLF)
while on ppc64le we have

0:  addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry foo,.-foo
addis 9,2,.LANCHOR0+1024@toc@ha
lfd 10,.LANCHOR0+1024@toc@l(9)
addis 9,2,.LANCHOR0+2048@toc@ha
lfd 11,.LANCHOR0+2048@toc@l(9)
addis 9,2,.LANCHOR0+3072@toc@ha
lfd 12,.LANCHOR0+3072@toc@l(9)
addis 9,2,.LANCHOR0+4096@toc@ha
lfd 0,.LANCHOR0+4096@toc@l(9)
addis 9,2,.LANCHOR0@toc@ha
stfd 10,.LANCHOR0@toc@l(9)
addis 9,2,.LANCHOR0+8@toc@ha
stfd 11,.LANCHOR0+8@toc@l(9)
addis 9,2,.LANCHOR0+16@toc@ha
stfd 12,.LANCHOR0+16@toc@l(9)
addis 9,2,.LANCHOR0+24@toc@ha
stfd 0,.LANCHOR0+24@toc@l(9)
blr

vs (cost model disabled):

0:  addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry foo,.-foo
addis 9,2,.LANCHOR0+2048@toc@ha
addis 8,2,.LANCHOR0@toc@ha
li 10,16
lfd 10,.LANCHOR0+2048@toc@l(9)
lfd 11,.LANCHOR0@toc@l(8)
addis 9,2,.LANCHOR0+3072@toc@ha
addis 8,2,.LANCHOR0+1024@toc@ha
lfd 12,.LANCHOR0+3072@toc@l(9)
lfd 0,.LANCHOR0+1024@toc@l(8)
addis 9,2,.LANCHOR0+131072@toc@ha
addi 9,9,.LANCHOR0+131072@toc@l
xxpermdi 12,10,12,0
xxpermdi 0,11,0,0
stxvd2x 12,9,10
stxvd2x 0,0,9
blr

both look comparatively ugly due to the loads of .LANCHOR uses.  I'd have
expected a lea of &a[0][0] and then offsetted addressing of that.  At least
it would avoid a ton of relocations.  Looks like 131072 wouldn't fit in
the 16 bits offset though.  Anyway - offtopic.  Whether the xxpermdi
makes it unprofitable to vectorize is not known to me.

[Bug fortran/96101] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2398

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
   Priority|P3  |P4

[Bug c++/96107] [11 regression] ICE on invalid c++: "Error reporting routines re-entered." when using -Wall

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Target Milestone|--- |11.0

[Bug c++/96106] [10/11 Regression] A friend abbreviated template function denies access to private members

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|A friend abbreviated|[10/11 Regression] A friend
   |template function denies|abbreviated template
   |access to private members   |function denies access to
   ||private members
  Known to fail||10.1.0, 11.0
  Known to work||9.3.0
   Last reconfirmed||2020-07-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
This was accepted with -std=gnu++2a -fconcepts until r276764, "Update the
concepts implementation to conform to C++20."

It's still accepted with -std=gnu++17 -fconcepts now.

[Bug c++/96097] ICE in dependent_type_p, at cp/pt.c:26326

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed, clang accepts the code. GCC ICEs for all revisions.

[Bug fortran/96100] [9/10/11 Regression] ICE in gimplify_expr, at gimplify.c:14638

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r9-6726-gd5f48c7c62d3d8cf.

[Bug fortran/96101] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2398

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Started with r6-3986-g38217d3ee7c6e1fe.

[Bug c++/96107] [11 regression] ICE on invalid c++: "Error reporting routines re-entered." when using -Wall

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Sergei Trofimovich  ---
Today's gcc does not crash. Bisected fix down to:

commit 67a493a0b9e7ce6caba4b8bedf1f3295e477ec00
Author: Martin Sebor 
Date:   Mon Jul 6 15:23:37 2020 -0600

Exclude calls to variadic lambda stubs from -Wnonnull checking (PR
c++/95984).

Resolves:
PR c++/95984 - Internal compiler error: Error reporting routines re-entered
in -Wnonnull on a variadic lamnda
PR c++/96021 - missing -Wnonnull passing nullptr to a nonnull variadic
lambda

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

[Bug c++/95984] [11 Regression] Internal compiler error: Error reporting routines re-entered. since r11-1697-g75ff24e1920ea6b1

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #6 from Sergei Trofimovich  ---
*** Bug 96107 has been marked as a duplicate of this bug. ***

[Bug c++/96097] ICE in dependent_type_p, at cp/pt.c:26326

[haoxintu at gmail dot com]

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

Haoxin Tu  changed:

   What|Removed |Added

 CC||haoxintu at gmail dot com

--- Comment #3 from Haoxin Tu  ---
(In reply to Martin Liška from comment #2)
> Confirmed, clang accepts the code. GCC ICEs for all revisions.

Hi,

I just realized I have reported an ice-on-invalid version in bug 95931 with the
same symptom in the trunk. Maybe you can consider them together.

Thanks,
Haoxin

[Bug c/96108] New: Different behavior in DSE pass

[499537630 at qq dot com]

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

Bug ID: 96108
   Summary: Different behavior in DSE pass
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 499537630 at qq dot com
  Target Milestone: ---

There are different behavior in DSE pass between gcc10 and gcc7.3. BUT I do not
known the correctness of dse_classify_store.

In gcc7.3, we could get DSE_STORE_DEAD when we get DSE_STORE_MABEY_PARTIAL_DEAD
with gcc10.


$ cat tauth.c 
struct aa;
static inline struct aa* get_aa(void) {
  struct aa* a;
  return a;
}
struct aa {
  int b;
};
void test()
{
  get_aa()->b &= 0xfff0;
}

$(7.3)aarch64_be-linux-gnu-gcc -S tauth.c -O2  -o - 
.arch armv8-a
.file   "tauth.c"
.text
.align  2
.p2align 3,,7
.global test
.type   test, %function
test:
.LFB1:
.cfi_startproc
ret
.cfi_endproc
.LFE1:
.size   test, .-test
.ident  "GCC: 7.3.0"
.section.note.GNU-stack,"",@progbits

$(10.1)aarch64_be-linux-gnu-gcc -S tauth.c -O2 -o -
.arch armv8-a
.file   "tauth.c"
.text
.align  2
.p2align 4,,11
.global test
.type   test, %function
test:
.LFB1:
.cfi_startproc
mov x0, 0
ldr w1, [x0]
and w1, w1, 65520
str w1, [x0]
ret
.cfi_endproc
.LFE1:
.size   test, .-test
.ident  "GCC:  10.1.0"
.section.note.GNU-stack,"",@progbits

[Bug testsuite/96109] New: gcc.dg/vect/slp-47.c etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 96109
   Summary: gcc.dg/vect/slp-47.c etc. FAIL
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11, arm*-*-*, ia64-suse-linux-gnu

The new gcc.dg/vect/slp-47.c and gcc.dg/vect/slp-48.c tests FAIL on various
targets, e.g. sparc-sun-solaris2.11 (both 32 and 64-bit):

+FAIL: gcc.dg/vect/slp-47.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorizing stmts using SLP" 2
+FAIL: gcc.dg/vect/slp-47.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 2
+FAIL: gcc.dg/vect/slp-48.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorizing stmts using SLP" 2
+FAIL: gcc.dg/vect/slp-48.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 2

IIUC the failure on SPARC is due to

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-47.c:12:19: missed: 
 not vectorized: unsupported unaligned load: y[_5]
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/slp-47.c:20:17: missed: 
 not vectorized: unsupported unaligned load: y[_2]

I'm attaching the dump for reference.

[Bug testsuite/96109] gcc.dg/vect/slp-47.c etc. FAIL

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 48844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48844&action=edit
32-bit sparc-sun-solaris2.11 slp-47.c.163t.vect

[Bug testsuite/96109] gcc.dg/vect/slp-47.c etc. FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/96110] New: Function declarator with a trailing return type "auto" should be allowed in try-catch block

[haoxintu at gmail dot com]

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

Bug ID: 96110
   Summary: Function declarator with a trailing return type "auto"
should be allowed in try-catch block
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

The code test.cc

int main(){
try {}
catch (auto foo() -> auto) {}
return 0;
}


might should be allowed in GCC.

$g++ test.cc
test.cc: In function 'int main()':
test.cc:8:12: error: 'auto' parameter not permitted in this context
8 | catch (auto foo() -> auto) {}
  |^~~~

Other compilers, clang, or icc accepts this well.

All versions from 6.1 to trunk behave the same.

Thanks,
Haoxin

[Bug tree-optimization/96108] Different behavior in DSE pass

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Keywords||missed-optimization
   Last reconfirmed||2020-07-08
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Did it only change when a is uninitialized or was this a reduction of a bigger
code and you reduced it too far?

[Bug fortran/96069] -ffile-prefix-map does not affect print in gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Fortran is not C, however it uses the traditional C preprocessor with some
problems (comments, ..., look at bugzilla for a list of them).

I am in favor to close this PR as WONTFIX.

[Bug fortran/96047] Bogus unitialized warning for derived type with allocatable components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
> At some compile-time cost we could also evaluate (but not actually optimize)
> branches when not optimizing.

Wouldn't be simpler to disable -Wmaybe-uninitialized at -O0?

[Bug testsuite/96109] gcc.dg/vect/slp-47.c etc. FAIL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-08

--- Comment #2 from Richard Biener  ---
Hmm, the loads should be all aligned ... but maybe we're not figuring they are.
Ah, so this is confusion in vect_compute_data_ref_alignment which does

  /* If this is a backward running DR then first access in the larger
 vectype actually is N-1 elements before the address in the DR.
 Adjust misalign accordingly.  */
  if (tree_int_cst_sgn (drb->step) < 0)
/* PLUS because STEP is negative.  */
misalignment += ((TYPE_VECTOR_SUBPARTS (vectype) - 1)
 * -TREE_INT_CST_LOW (TYPE_SIZE_UNIT (TREE_TYPE
(vectype;

but that's of course not the ideal place to do this because the actual
DRs alignment is _not_ different.  And in fact for SLP the above is even
bogus - I suppose we might even end up with wrong code in case the above
would make the access appear aligned.

[Bug tree-optimization/96108] Different behavior in DSE pass

[499537630 at qq dot com]

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

--- Comment #2 from Jolyon <499537630 at qq dot com> ---
(In reply to Andrew Pinski from comment #1)
> Did it only change when a is uninitialized or was this a reduction of a
> bigger code and you reduced it too far?

Or you could fix the tauth.c???
$cat tauth.c
struct aa;
static inline struct aa* get_aa(void) {
  struct aa* a;
  return a;
}
struct aa {
  int b;
};
int main()
{
  get_aa()->b &= 0xfff0;
  return 0;
}

[Bug tree-optimization/96108] Different behavior in DSE pass

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Fix?  The code invokes UB, anything can happen.  The only thing that needs
fixing is the testcase.

[Bug target/95030] Conflicting report about VIA eden's AVX capabilities

[arthur200126 at gmail dot com]

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

--- Comment #2 from Mingye Wang  ---
For the sake of completeness, a lot of extra CPUID info is available from
http://users.atw.hu/instlatx64/. This bug will apply to Zhaoxin too, likely as
an alias.

[Bug testsuite/96109] gcc.dg/vect/slp-47.c etc. FAIL

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
OK, it's indeed wrong which means we'd fall through the checks that prevent
SPARC from vectorizing here but then we'll create an unaligned access
anyway (because VMAT_STRIDED_SLP is too lazy to figure out appropriate
alignment).  We're also assuming element alignment there.

static double x[1024], y[1024];

void __attribute__((noipa))
foo ()
{
  for (int i = 0; i < 511; ++i)
{
  x[2*i] = y[1022 - 2*i - 1];
  x[2*i+1] = y[1022 - 2*i];
}
}

int main()
{
  for (int i = 0; i < 1024; ++i)
x[i] = 0, y[i] = i;
  foo ();
  for (int i = 0; i < 1022; ++i)
if (x[i] != y[1022 - (i^1)])
  __builtin_abort ();
  if (x[1022] != 0 || x[1023] != 0)
__builtin_abort ();
  return 0;
}

[Bug c++/96111] New: checking type of attribute with concepts results in compilation error or ICE

[lts-rudolph at gmx dot de]

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

Bug ID: 96111
   Summary: checking type of attribute with concepts results in
compilation error or ICE
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lts-rudolph at gmx dot de
  Target Milestone: ---

Code fails to compile with gcc 10.1.1 ( unexpected compile error messages )
and compilation fails with ICE on current trunk

if checking in the requirement with only the commented lines, everything works
fine.  

compiled with: g++ --std=c++20 main.cpp -O2 -g 

struct N
{
char value;
auto Get() { return value; }
};

struct M
{
int value;
auto Get() { return value; }
};

void func3( auto n ) 
requires requires
{
//{ n.Get() } -> std::same_as;
{ n.value } -> std::same_as;
}
{
std::cout << __PRETTY_FUNCTION__ << std::endl;
}


void func3( auto n ) 
requires requires 
{
//{ n.Get() } -> std::same_as;
{ n.value } -> std::same_as;
}
{
std::cout << __PRETTY_FUNCTION__ << std::endl;
}

int main()
{
func3( n );
func3( m );
}

[Bug target/96030] AArch64: Add an option to control 64bits simdclone of math functions for fortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

  Component|fortran |target

--- Comment #4 from Dominique d'Humieres  ---
Target specific and has very little to do with fortran.

s/provide/provided/

[Bug tree-optimization/96108] Different behavior in DSE pass

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
During optimization, we often have branches with dead code that would exhibit
UB if it was ever executed. Cleaning up those branches as much as possible
helps reduce code size, show that some variables (in the live part of the code)
are constant, etc.

If we see *p=x where p is uninitialized, it doesn't serve much purpose to keep
it as is, we might as well replace it with *0=0 or trap/unreachable depending
on options.

[Bug tree-optimization/96108] Different behavior in DSE pass

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
The testcase is of course invoking undefined behavior since it dereferences an
uninitialized pointer.  I'm not sure there was intentional changes to DSE here
but eliding the store looks reasonable to me (though replacing it with a
trap might be good as well - see other discussions about undefinedness).

Thus confirmed - 7.5 removes the store while trunk does not.  But it may
be a deliberate change.

[Bug fortran/92702] [F2008] (and hence [F2018]) Implement VALUE support for arrays + deferred-length parameters

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-08
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Is there a meta-bug for F2088/F2018 missing features?

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-08

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. Quite complex test case!

[Bug fortran/95682] [9/10/11 Regression] Default assignment fails with allocatable array of deferred-length strings

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |9.4
   Last reconfirmed||2020-07-08
   Priority|P3  |P4
 Ever confirmed|0   |1
  Known to work||8.4.1
  Known to fail||10.1.0, 11.0, 9.3.0
Summary|Default assignment fails|[9/10/11 Regression]
   |with allocatable array of   |Default assignment fails
   |deferred-length strings |with allocatable array of
   ||deferred-length strings

--- Comment #1 from Dominique d'Humieres  ---
The change occurred between revisions r264542 (2018-09-24, OK) and r264595
(2018-09-26, wrong code).

[Bug libgomp/96112] New: [OpenACC] 'acc_is_present' if 'byte length is zero'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 96112
   Summary: [OpenACC] 'acc_is_present' if 'byte length is zero'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

Ever since OpenACC 2.0a (the first we implemented), 3.2.29 "acc_is_present"
states that "If the byte length is zero, the function returns ['true'] if the
given address is present at all on the device".  We return 'false'.

This especially should then also do the right thing for a testcase involving a
"zero-length array section" (OpenMP terminology); untested:

int n = 0;
int a[n];
#pragma acc data create(a[0:n])
  {
assert(acc_is_present(a, 0));
  }

[Bug libstdc++/96113] New: std::vector | std::views::drop_while | std::views::reverse, cbegin does not work

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 96113
   Summary: std::vector | std::views::drop_while |
std::views::reverse, cbegin does not work
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hi gcc-team,

the following code does not compile:

```
#include 
#include 

int main()
{
std::vector text1{};
auto && view = text1
 | std::views::drop_while([](auto const &){ return false; })
 | std::views::reverse;

std::ranges::cbegin(view);
}
```

with `g++-10 -std=c++2a` (see https://godbolt.org/z/adxYy-)

Thank you!

[Bug libgomp/96112] [OpenACC] 'acc_is_present' if 'byte length is zero'

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Note, the mapping of objects with zero size is fuzzy at least in OpenMP and
generally, when one just gets a pointer, if there are zero sized objects
involved, one doesn't know if it is the end of some earlier object, a zero
sized object at that address (could be many of them) or non-zero sized object
starting at that address.
E.g. in C++ zero sized objects aren't valid and I think in C aren't either,
except for GNU extensions.
The OpenMP concept of zero sized array sections is about asking to map zero
bytes and essentially either get whatever object is at that address, or NULL if
it is not mapped, so something that is implicitly done for pointers.  It will
not work reliably in presence of zero sized objects mapped at that point.

[Bug fortran/94975] Address sanitizations show heap-buffer-overflow with class(*) allocated to character on assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-08

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from at least GCC7.

[Bug libstdc++/96113] std::vector | std::views::drop_while, cbegin does not work

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

gcc-bugs at marehr dot dialup.fu-berlin.de changed:

   What|Removed |Added

Summary|std::vector |   |std::vector |
   |std::views::drop_while ||std::views::drop_while,
   |std::views::reverse, cbegin |cbegin does not work
   |does not work   |

--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Sorry, we have a view which is similar to `std::views::drop_while` where I
could just replace the name and it gave me the same error, but using
`std::views::drop_while` gives me the error already without the reverse. So I
changed the ticket.

```c++
#include 
#include 

int main()
{
std::vector text1{};
auto drop_none = [](auto const &) constexpr { return false; };
auto accept_any = [](auto const &) constexpr { return true; };
auto && view1 = text1 | std::views::reverse;
auto && view2 = text1 | std::views::drop_while(drop_none);
auto && view3 = text1 | std::views::take_while(accept_any);
auto && view4 = text1 | std::views::filter(accept_any);

std::ranges::cbegin(view1);
std::ranges::cbegin(view2); // does not work
std::ranges::cbegin(view3);
std::ranges::cbegin(view4); // does not work
}
```

(https://godbolt.org/z/E97_Tq)

[Bug c++/95935] ICE : Segmentation fault crash_signal from toplev.c:328

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
If we want to fix this generally, we'll have to introduce the notion of
defining-type-specifier, introduced in CWG 2141, to the parser.  (Also see CWG
686.)

[Bug fortran/95998] New: gfc_typename use of static memory

[dominiq at lps dot ens.fr]

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

Bug ID: 95998
   Summary: gfc_typename use of static memory
   Product: gcc
   Version: unknown
Status: WAITING
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---
Status: WAITING
  Last reconfirmed: 2020-07-08
Ever confirmed: 1

The comment in misc.c says it all...

/* Return a string describing the type and kind of a typespec.  Because
   we return alternating buffers, this subroutine can appear twice in
   the argument list of a single statement.  */

Did we really audit our code to make sure we keep to this restriction? :-|

--- Comment #1 from Dominique d'Humieres  ---
Is static in C/C++ equivalent of SAVE in fortran (at least in the context of
gfc_typename)?

If yes, AFAIU the code the odd access to gfc_typename use buffer2, while even
ones
use buffer1? Wouldn't it be simple (safer?) to use only buffer1?

  static char buffer[GFC_MAX_SYMBOL_LEN + 7];  /* 7 for "TYPE()" + '\0'.  */
  gfc_typespec *ts1;
  gfc_charlen_t length = 0;

Same thing for gfc_dummy_typename, gfc_typename, ... .

[Bug libfortran/95293] Fortran not passing array by reference

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #8 from Dominique d'Humieres  ---
Isn't it an aliasing problem?

[Bug fortran/95196] Assumed-rank incorrect array bounds inside select rank

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
This seems fixed on GCC11 (GCC10 stops with STOP 11).

[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-08

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from at least GG7.

Note that I didn't check the validity of the expectations.

[Bug c++/96111] checking type of attribute with concepts results in compilation error or ICE

[lts-rudolph at gmx dot de]

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

--- Comment #1 from Klaus Rudolph  ---
The error massages are valid as 

as got by an answr on SO (
https://stackoverflow.com/questions/62791460/checking-type-of-attribute-with-concepts
)


[expr.prim.req.compound]/1.3

If the return-type-requirement is present, then:
Substitution of template arguments (if any) into the
return-type-requirement is performed.
The immediately-declared constraint ([temp.param]) of the
type-constraint for decltype((E)) shall be satisfied.

E is our expression, namely n.value.

Now, decltype(n.value) is char or int, that's because decltype has a special
rule for class member access and id expressions. But decltype((n.value)) is
char& or int&. The value category is encoded in the type of decltype when
dealing with a general expression (such as a parenthesized class member
access).

BUT: That we see an ICE on current trunk is a bug!

[Bug c++/95972] ICE in check_member_template, at cp/decl2.c:570

[haoxintu at gmail dot com]

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

--- Comment #2 from Haoxin Tu  ---
Update a new case.

Input:
int a() { [] ( auto class {int b()}}

Output:
: In function 'int a()':
:1:27: error: types may not be defined in parameter types
1 | int a() { [] ( auto class {int b()}}
  |   ^
:1:34: internal compiler error: in check_member_template, at
cp/decl2.c:568
1 | int a() { [] ( auto class {int b()}}
  |  ^

[Bug fortran/96069] -ffile-prefix-map does not affect print in gfortran

[yyc1992 at gmail dot com]

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

--- Comment #2 from Yichao Yu  ---
Why should this feature be c only?

[Bug libstdc++/96113] std::vector | std::views::drop_while, cbegin does not work

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Thanks for the report.  I think this is behaving as specified though.  The
views drop_while_view, filter_view and reverse_view according to the spec do
not have a const-qualified begin() member, so ranges::cbegin won't work on
them.

(I think this is because their begin() must in general cache its result within
the view object so that the function has amortized constant time complexity.)

[Bug preprocessor/96069] -ffile-prefix-map does not affect print in gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

  Component|fortran |preprocessor

--- Comment #3 from Dominique d'Humieres  ---
> Why should this feature be c only?

Apparently it is. Let move the component to 'preprocessor'.

[Bug preprocessor/96069] -ffile-prefix-map does not affect print in gfortran

[yyc1992 at gmail dot com]

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

--- Comment #4 from Yichao Yu  ---
> Apparently it is.

Yes, but my question is about why should this be "WONTFIX". This feature
(reproducible build) is certainly as useful in fortran as it is in C family.

> Let move the component to 'preprocessor'.

At least for the issue for the fortran code I had it doesn't seem to be in the
preprocessor. I do agree that other frontends should probably use this too but
I have no idea what are the cases they should do it.

Also note that I've already submitted patches to fix this though I haven't got
a reply yet.

[Bug preprocessor/96069] -ffile-prefix-map does not affect print in gfortran

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Also note that I've already submitted patches to fix this though
> I haven't got a reply yet.

Where did you submit the patches?

[Bug c++/95910] transform view in combination with single view calls const qualified begin even if it is not const

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
(In reply to Rene Rahn from comment #2)
> Ok, thanks for the explanation. I do understand the issue now and why it
> causes the hard error and not an substitution failure. 
> But honestly, given that it works for container because they are wrapped in
> a ref_view with pointer semantics, makes this very hard to understand.

Hmm yes, it seems (for the record) the reason this works for std::vector is
because views::transform wraps the type in a ref_view, and ref_view's
const-qualified begin() member returns a non-const iterator.  So both
range_reference_t<_Vp> and range_reference_t (where _Vp =
ref_view>) resolve to int&.

On the other hand, single_view's const-qualified begin() member returns a
pointer to const T, so range_reference_t (with _Vp = single_view)
resolves to const int&.  And so when we go to check the constraints of 
transform_view::begin() const we end up instantiating the lambda with a const
int& argument, leading to a hard error.

> And basically, if you transform something that calls somewhere in the stack a
> function with auto return type you might not be able to even do
> `decltype(expression)` to get the return type deduced any more, because the
> compiler has to instantiate the expression. 
> 
> That makes generic code with auto return types kind of difficult to use,
> does it? I mean, especially as a library writer I must make sure that the
> client can use my methods/types in these contexts. And it feels plausible
> that types are constrained to be mutable somewhere in this context.
> Is there a general trick to avoid this, except guaranteeing to know the
> return type before the expression is evaluated?

Hmm, if you can't easily specify a concrete return type, then you could maybe
try constraining the lambda appropriately.  In this particular example you
could replace the static_assert with an analogous require-clause, which would
turn the hard error into a SFINAE-friendly error.

We've also been bitten by using a deduced auto return type instead of a
concrete return type, in particular in the definitions of the ranges::empty()
and ranges::iter_move() CPOs, see e.g. PR93978 and PR92894. 

> 
> Many thanks for your help!

[Bug preprocessor/96069] -ffile-prefix-map does not affect print in gfortran

[yyc1992 at gmail dot com]

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

--- Comment #6 from Yichao Yu  ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549411.html

and

https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549413.html

[Bug c++/96103] Unclear diagnostic for a function return with "decltype(auto)"

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r11-1913-ga51de1af063b0a9233762dcd6ecf2ea0bdf4cdff
Author: Marek Polacek 
Date:   Tue Jul 7 17:09:42 2020 -0400

c++: Better diagnostic for decltype(auto) in C++11 [PR96103]

If you try to use decltype(auto) in C++11, we emit obscure

  error: expected primary-expression before 'auto'

giving the user no hint as to what's wrong.  This patch improves that
diagnostic.  Since we've been giving an error, I'm also using error().

gcc/cp/ChangeLog:

PR c++/96103
* parser.c (cp_parser_decltype): Print error about using
decltype(auto)
in C++11.  Check that the token following "auto" is ")".

gcc/testsuite/ChangeLog:

PR c++/96103
* g++.dg/cpp0x/decltype77.C: New test.

[Bug target/95105] Bogus reference-compatibility error for arm_sve_vector_bits

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8436-gecd56bc41563a84808fe4e1a2c7341bf8a621c92
Author: Richard Sandiford 
Date:   Wed Jul 8 14:34:11 2020 +0100

aarch64: Fix arm_sve_vector_bits on typedefs [PR95105]

Compiling this testcase with -march=armv8.2-a+sve
-msve-vector-bits=512:

--
typedef __SVFloat32_t foo;
typedef foo bar __attribute__((arm_sve_vector_bits(512)));
template struct s { T x; };
extern s a;
bar &b = a.x;
--

gave the bogus error:

  cannot bind non-const lvalue reference of type âbar&â to an rvalue
  of type âbarâ

The testcase works if the attribute is applied directly
to __SVFloat32_t instead of via foo.

This shows a more general problem with the way that we were handling
the arm_sve_vector_bits attribute: we started by building a distinct
copy of the type to which the attribute was applied, instead of starting
with its main variant.  This new type then became its own main variant,
meaning that the relationship between types that have the attribute
could be different from the relationship between types that don't have
the attribute.

This patch instead copies the main variant of the original type and then
reapplies all the differences.

gcc/
PR target/95105
* config/aarch64/aarch64-sve-builtins.cc
(handle_arm_sve_vector_bits_attribute): Create a copy of the
original type's TYPE_MAIN_VARIANT, then reapply all the differences
between the original type and its main variant.

gcc/testsuite/
PR target/95105
* gcc.target/aarch64/sve/acle/general/attributes_8.c: New test.
* g++.target/aarch64/sve/acle/general-c++/attributes_1.C: Likewise.

[Bug c++/96103] Unclear diagnostic for a function return with "decltype(auto)"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug tree-optimization/96114] New: ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[marxin at gcc dot gnu.org]

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

Bug ID: 96114
   Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:279 since
r7-536-g381cdae49785fc4b
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

One old one:

$ cat vlt_to_pointer.c
int test_n;

void
test(int (*fn())[test_n]) { (*fn())[0]; }

void
main_fn() { test(main_fn); }

$ gcc vlt_to_pointer.c -fsanitize=bounds-strict -O1 -finline-small-functions
-fnon-call-exceptions -ftrapv -fexceptions -c
vlt_to_pointer.c: In function ‘main_fn’:
vlt_to_pointer.c:7:18: warning: passing argument 1 of ‘test’ from incompatible
pointer type [-Wincompatible-pointer-types]
7 | main_fn() { test(main_fn); }
  |  ^~~
  |  |
  |  void (*)()
vlt_to_pointer.c:4:12: note: expected ‘int (* (*)())[(sizetype)(test_n)]’ but
argument is of type ‘void (*)()’
4 | test(int (*fn())[test_n]) { (*fn())[0]; }
  |  ~~^
during GIMPLE pass: einline
vlt_to_pointer.c:7:13: internal compiler error: in make_ssa_name_fn, at
tree-ssanames.c:279
7 | main_fn() { test(main_fn); }
  | ^
0x779eccc9 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/96113] std::vector | std::views::drop_while, cbegin does not work

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

gcc-bugs at marehr dot dialup.fu-berlin.de changed:

   What|Removed |Added

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

--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Ah, thank you, you are right! I always forget that they are cached in the view
when calling begin and not when constructing the view. This makes the view
strictly speaking still not amortized constant, but helps to reduce the runtime
on multiple invocations of `begin`. 

The question is if `std::views::reverse_view`, which basically makes it a
common range, can recover the const-iterability. Like it can do for
sized-ranges.

I have just seen that `std::views::reverse_view` requires a common_range for
const overloads of begin/end, this might be my original use case, because I
have a const-iterable, bi-directional view with a sentinel.

But since the standard explicitly drops the const-iterability when using
`drop_while` / non-common views for `reverse_view`, I think this issue can be
closed.

Thank you!

[Bug preprocessor/96069] -ffile-prefix-map does not affect print in gfortran

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
If you need to get the gfortran developers attention, you must submit your
patch to fort...@gcc.gnu.org.

[Bug preprocessor/96069] -ffile-prefix-map does not affect print in gfortran

[yyc1992 at gmail dot com]

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

--- Comment #8 from Yichao Yu  ---
OK, done. It would be nice to mention it on
https://gcc.gnu.org/contribute.html#patches

[Bug c++/95910] transform view in combination with single view calls const qualified begin even if it is not const

[rene.r...@fu-berlin.de]

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

--- Comment #4 from Rene Rahn  ---
> Hmm, if you can't easily specify a concrete return type, then you could maybe 
> > try constraining the lambda appropriately.  In this particular example you 
> could replace the static_assert with an analogous require-clause, which would 
> > turn the hard error into a SFINAE-friendly error.

Yes, this is basically what I would do know (AFAIK also recommended to always
constraint generic types). In this case I could work with an explicit return
type, though.

Many thanks for your support and time.

[Bug tree-optimization/95694] [9/10/11 Regression] ICE in trunc_int_for_mode, at explow.c:59 since r9-7156-g33579b59aaf02eb7

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:760df6d296b8fc59796f42dca5eb14012fbfa28b

commit r11-1914-g760df6d296b8fc59796f42dca5eb14012fbfa28b
Author: Richard Sandiford 
Date:   Wed Jul 8 15:01:14 2020 +0100

expr: Fix REDUCE_BIT_FIELD for constants [PR95694]

This is yet another PR caused by constant integer rtxes not storing
a mode.  We were calling REDUCE_BIT_FIELD on a constant integer that
didn't fit in poly_int64, and then tripped the as_a
assert on VOIDmode.

AFAICT REDUCE_BIT_FIELD is always passed rtxes that have TYPE_MODE
(rather than some other mode) and it just fills in the redundant
sign bits of that TYPE_MODE value.  So it should be safe to get
the mode from the type instead of the rtx.  The patch does that
and asserts that the modes agree, where information is available.

That on its own is enough to fix the bug, but we might as well
extend the folding case to all constant integers, not just those
that fit poly_int64.

gcc/
PR middle-end/95694
* expr.c (expand_expr_real_2): Get the mode from the type rather
than the rtx, and assert that it is consistent with the mode of
the rtx (where known).  Optimize all constant integers, not just
those that can be represented in poly_int64.

gcc/testsuite/
PR middle-end/95694
* gcc.dg/pr95694.c: New test.

[Bug c/96114] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-08
 Status|UNCONFIRMED |NEW
  Component|tree-optimization   |c
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Yet another testcase for a latent frontend bug which misses a
DECL_EXPR for VLAs.

[Bug c++/95972] ICE in check_member_template, at cp/decl2.c:570

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
(In reply to Haoxin Tu from comment #1)
> Hi, there.
> 
> I guess I shouldn't use C-Reduce to reduce my ICE on invalid code cases.
> After using C-Reduce, the cases are more like a "garbage" code.

You can still use creduce (I do), but it's good to try adding missing
parens/braces and similar to make the code more sensible.

[Bug c++/96110] Function declarator with a trailing return type "auto" should be allowed in try-catch block

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
What is that even supposed to mean?

Rejecting it seems right to me.

[Bug c++/96110] Function declarator with a trailing return type "auto" should be allowed in try-catch block

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
This isn't specific to catch handlers, other compilers accept that nonsense
function declaration in various contexts, and GCC rejects them all:

using F = auto () -> auto;
template struct X { };
X auto> x;


But if you ask Clang to generate debug info for this code it ICEs.

[Bug c++/96110] Function declarator with a trailing return type "auto" should be allowed in try-catch block

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
And this puts Clang into a coma even without debuginfo:

template struct X { T* p; };
X auto> x;

[Bug c++/96111] checking type of attribute with concepts results in compilation error or ICE

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
$ ./cc1plus -quiet 96111.C -std=c++20
96111.C:17:25: error: ‘same_as’ in namespace ‘std’ does not name a template
type
   17 | { n.value } -> std::same_as;
  | ^~~
96111.C:17:32: error: expected primary-expression before ‘<’ token
   17 | { n.value } -> std::same_as;
  |^
96111.C:17:33: error: expected primary-expression before ‘int’
   17 | { n.value } -> std::same_as;
  | ^~~
96111.C:18:1: internal compiler error: Segmentation fault
   18 | }
  | ^
0x15ab9e2 crash_signal
/home/mpolacek/src/gcc/gcc/toplev.c:328
0x7f3832570aaf ???
   
/usr/src/debug/glibc-2.31-17-gab029a2801/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x927ed5 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/mpolacek/src/gcc/gcc/tree.h:3302
0xa42223 grokfndecl
/home/mpolacek/src/gcc/gcc/cp/decl.c:9441
0xa51481 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/mpolacek/src/gcc/gcc/cp/decl.c:13640
0xa5f431 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
/home/mpolacek/src/gcc/gcc/cp/decl.c:16566
0xb6e019 cp_parser_function_definition_from_specifiers_and_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:28945
0xb5d6ca cp_parser_init_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:20732
0xb50875 cp_parser_simple_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:13786
0xb50417 cp_parser_block_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:13612
0xb50105 cp_parser_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:13484
0xb501f5 cp_parser_toplevel_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:13513
0xb3cd90 cp_parser_translation_unit
/home/mpolacek/src/gcc/gcc/cp/parser.c:4761
0xb9c1b8 c_parse_file()
/home/mpolacek/src/gcc/gcc/cp/parser.c:44054
0xd66afb c_common_parse_file()
/home/mpolacek/src/gcc/gcc/c-family/c-opts.c:1194
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/95105] Bogus reference-compatibility error for arm_sve_vector_bits

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug target/95105] Bogus reference-compatibility error for arm_sve_vector_bits

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
…and closed.

[Bug c++/96110] Function declarator with a trailing return type "auto" should be allowed in try-catch block

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
This is not valid code. GCC is right to reject it.

[Bug c++/96110] Function declarator with a trailing return type "auto" should be allowed in try-catch block

[haoxintu at gmail dot com]

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

--- Comment #5 from Haoxin Tu  ---
(In reply to Jonathan Wakely from comment #2)
> This isn't specific to catch handlers, other compilers accept that nonsense
> function declaration in various contexts, and GCC rejects them all:

Thanks for your clarifying, this is a misunderstanding of mine.

[Bug c++/95972] ICE in check_member_template, at cp/decl2.c:570

[haoxintu at gmail dot com]

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

--- Comment #4 from Haoxin Tu  ---
(In reply to Marek Polacek from comment #3)

> You can still use creduce (I do), but it's good to try adding missing
> parens/braces and similar to make the code more sensible.

Yes, you are right. Thanks for you advise, and I am doing this like what you
said.

[Bug c++/96115] New: Char literal, decays to a pointer when passed to function pointer

[boris_oncev at hotmail dot com]

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

Bug ID: 96115
   Summary: Char literal, decays to a pointer when passed to
function pointer
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris_oncev at hotmail dot com
  Target Milestone: ---

Example code:
struct SL{
template 
SL(const char (&Str)[N]) {}
};

int foo(SL x) {
return 2;
}

int main() {
int (*f)(SL) = &foo;
foo("asd"); // works fine
f("asd"); // error could not convert '(const char*) to SL
}

Godbot link:
https://godbolt.org/z/vo8lOf

works on other compilers clang, msvc and icc

[Bug c++/96110] Function declarator with a trailing return type "auto" should be allowed in try-catch block

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
I've reported https://bugs.llvm.org/show_bug.cgi?id=46637

[Bug c++/96116] New: GCC accepts "enum struct/class" in reference to enumeration

[haoxintu at gmail dot com]

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

Bug ID: 96116
   Summary: GCC accepts "enum struct/class" in reference to
enumeration
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi,all.

This code, might be an invalid code, but GCC accepts it.

$cat test.cc
using alias1 = enum struct E1;
using alias2 = enum class E2;

While in clang:
$clang++ test.cc
test.cc:1:21: error: reference to enumeration must use 'enum' not 'enum struct'
[-Welaborated-enum-class]
using alias1 = enum struct E1;
^~~
test.cc:2:21: error: reference to enumeration must use 'enum' not 'enum class'
[-Welaborated-enum-class]
using alias2 = enum class E2;
^~
2 errors generated.


Here is a related bug report in llvm:
https://bugs.llvm.org/show_bug.cgi?id=46603

They suggested that ""enum class" can only be used when defining an enumeration
or as part of a standalone forward declaration"

Versions from 6.1 to trunk behave the same. So is this an invalid code for GCC?

Thanks,
Haoxin

[Bug c++/95910] transform view in combination with single view calls const qualified begin even if it is not const

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
No problem, thanks for the report.

[Bug c++/96117] New: Cannot mix c++11-style and GCC-style attributes

[steveire at gmail dot com]

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

Bug ID: 96117
   Summary: Cannot mix c++11-style and GCC-style attributes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steveire at gmail dot com
  Target Milestone: ---

```
struct __attribute__((visibility("default"))) [[deprecated("a message")]] A1
{

};

struct __attribute__((__deprecated__("a message")))
__attribute__((visibility("default"))) A2
{

};

```

A EXPORT macro containing a GCC-style visibility attribute (generated by CMake)
and another macro containing a c++11-style macro can not be used to decorate a
class.

https://godbolt.org/z/qHxr6s

[Bug c++/96116] GCC accepts "enum struct/class" in reference to enumeration

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Antal Buss from comment #1)
> Created attachment 48811 [details]
> Preprocessed file

For convenience, that is:

#include 

int main() {
  auto t = std::jthread([](){});
  t.request_stop();
  return 0;
}


Both this testcase and the one in comment 7 work fine on RHEL 7, so this does
appear to be a regression caused by the changes for
https://sourceware.org/bugzilla/show_bug.cgi?id=22635

[Bug c++/96118] New: GCC accepts invalid combination of two type specifiers

[haoxintu at gmail dot com]

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

Bug ID: 96118
   Summary: GCC accepts invalid combination of two type specifiers
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This code, combines a typedef specifier and a normal type specifier, might be
an invalid code. 

$cat test.cc
typedef long typedef_long;
typedef_long long var = 10;

GCC accept this well.

While in clang:
error: 'long type-name' is invalid

in icc:
error: invalid combination of type specifiers

in msvc:
error C2628: 'typedef_long' followed by 'long' is illegal (did you forget a
';'?)

All versions from GCC 4.0 to trunk behave the same.

Thanks,
Haoxin

[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-07-08
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jonathan Wakely  ---
(In reply to ensadc from comment #0)
> It seems that in this case, `iter_difference_t` is treated as an alias of
> `std::iterator_traits>::difference_type` (which
> doesn't exist), because libstdc++ defines a specialization of
> `std::iterator_traits>`.

That specialization is required, see [counted.iterator], and we define it
correctly.

This seems to be a defect in C++20. iter_difference_t is required to use
iterator_traits::difference_type if iterator_traits is specialized, which
it is here. But the specialization doesn't define difference_type.

It doesn't matter that incrementable_traits::difference_type is defined,
because it doesn't get used.

I think the fix is (untested):

--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -2141,16 +2141,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   iter_difference_t<_It> _M_length = 0;
 };

-  template
-struct incrementable_traits>
-{
-  using difference_type = iter_difference_t<_It>;
-};
-
   template
 struct iterator_traits> : iterator_traits<_It>
 {
   using pointer = void;
+  using difference_type = iter_difference_t<_It>;
 };
 #endif // C++20

[Bug c++/96119] New: GCC accepts invalid qualifier in a try-catch block

[haoxintu at gmail dot com]

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

Bug ID: 96119
   Summary: GCC accepts invalid qualifier in a try-catch block
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This code might be an invalid code, but GCC accepts this well.

$cat test.cc
int main(){
try {}
catch (int () & ){}
return 0;
}

While in Clang, it says:
error: non-member function cannot have '&' qualifier

In ICC:
error: a ref-qualifier is not allowed here

All GCC versions from 5.1 to trunk behave the same.

Is this also an invalid code for GCC or is there something I misunderstanding?

Thanks,
Haoxin

[Bug tree-optimization/96022] ICE during GIMPLE pass: slp in operator[], at vec.h:867

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||mkuvyrkov at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #5 from Maxim Kuvyrkov  ---
Hi Richard,

This causes ICEs on many vectorization testcases for arm-linux-gnueabihf.  Full
list of regressions is at [1].  Sum and log files are at [2].

[1]
https://ci.linaro.org/view/tcwg_cross/job/tcwg_cross-bisect-gnu-master-arm-check_cross/7/artifact/artifacts/build-first_bad/results/*view*/
[2]
https://ci.linaro.org/view/tcwg_cross/job/tcwg_cross-bisect-gnu-master-arm-check_cross/7/artifact/artifacts/build-first_bad/sumfiles/
 

Typical error log:

spawn -ignore SIGHUP
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-unknown-linux-gnu/bin/arm-linux-gnueabihf-gcc
--sysroot=/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/sysroots/arm-linux-gnueabihf
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/vect/pr55857-1.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never
--sysroot=/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/sysroots/arm-linux-gnueabihf
-mfpu=neon -ffast-math -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o pr55857-1.s
during GIMPLE pass: vect
dump file: pr55857-1.c.163t.vect
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/vect/pr55857-1.c:
In function 'foo':
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/vect/pr55857-1.c:4:1:
internal compiler error: Segmentation fault
0xcd933f crash_signal
   
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/toplev.c:328
0xf889ee get_vectype_for_scalar_type(vec_info*, tree_node*, _slp_tree*)
   
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/tree-vect-stmts.c:10999
0xf889ee vectorizable_shift
   
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/tree-vect-stmts.c:5404
0xfa3dbf vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
   
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/tree-vect-stmts.c:10555
0xfbc5b9 vect_analyze_loop_operations
   
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/tree-vect-loop.c:1613
0xfbeb14 vect_analyze_loop_2
   
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/tree-vect-loop.c:2164
0xfbeb14 vect_analyze_loop(loop*, vec_info_shared*)
   
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/tree-vect-loop.c:2612
0xfe206c try_vectorize_loop_1
   
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/tree-vectorizer.c:955
0xfe2f09 vectorize_loops()
   
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/tree-vectorizer.c:1189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/vect/pr55857-1.c (internal compiler error)
FAIL: gcc.dg/vect/pr55857-1.c (test for excess errors)


GCC was configured as a typical armhf cross-compiler:
 --disable-multilib --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb
--with-tune=cortex-a9 --with-arch=armv7-a --enable-threads=posix
--enable-multiarch --enable-libstdcxx-time=yes --enable-gnu-indirect-function
--enable-checking=yes --disable-bootstrap --enable-languages=c,c++,fortran,lto
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=arm-linux-gnueabihf

[Bug tree-optimization/96022] ICE during GIMPLE pass: slp in operator[], at vec.h:867

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #6 from Richard Biener  ---
Wasn't this already fixed?  See PR96037.  Please do not re-open bugs for bugs
with obviously different cause.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=22635

--- Comment #13 from Jonathan Wakely  ---
I'm testing this:

diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
index 965247602ac..0af84a781e5 100644
--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -684,7 +684,12 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
 static inline __gthread_t
 __gthread_self (void)
 {
+#if __GLIBC_PREREQ(2, 27)
+  /* See PR libstdc++/95989  */
+  return pthread_self ();
+#else
   return __gthrw_(pthread_self) ();
+#endif
 }

 static inline int
diff --git a/libstdc++-v3/include/std/thread b/libstdc++-v3/include/std/thread
index 0445ab1e319..2772dd3950e 100644
--- a/libstdc++-v3/include/std/thread
+++ b/libstdc++-v3/include/std/thread
@@ -364,13 +364,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline thread::id
 get_id() noexcept
 {
-#ifdef __GLIBC__
+#if defined __GLIBC__ && ! __GLIBC_PREREQ(2, 27)
   // For the GNU C library pthread_self() is usable without linking to
-  // libpthread.so but returns 0, so we cannot use it in single-threaded
-  // programs, because this_thread::get_id() != thread::id{} must be true.
-  // We know that pthread_t is an integral type in the GNU C library.
+  // libpthread, but prior to version 2.27 the version in libc returns 0,
+  // which breaks the invariant this_thread::get_id() != thread::id{}.
+  // We know that pthread_t is a scalar type in the GNU C library,
+  // so just use (__gthread_t)1 as the ID of the main (and only) thread.
   if (!__gthread_active_p())
-   return thread::id(1);
+   return thread::id((__gthread_t)1);
 #endif
   return thread::id(__gthread_self());
 }

[Bug c++/96118] GCC accepts invalid combination of two type specifiers

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is a duplicate of an existing bug.

[Bug c++/96119] GCC accepts invalid qualifier in a try-catch block

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-07-08
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
GCC seems to treat that as int(), which decays to int(*)().

[Bug c++/96117] Cannot mix c++11-style and GCC-style attributes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-08
 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This one works too of course, but isn't helpful if you don't control the
macros:

struct [[gnu::visibility("default")]] [[deprecated("a message")]]  A3 { };

[Bug c++/96120] New: Ambiguity diagnostic message of "invalid use of type 'void' in parameter declaration"

[haoxintu at gmail dot com]

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

Bug ID: 96120
   Summary: Ambiguity diagnostic message of "invalid use of type
'void' in parameter declaration"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This code, test.cc, GCC might emit the ambiguity diagnostic message on it.

$cat test.cc
void foo1 (void) {}
void foo2 (void, int){}

$g++ -c test.cc
test.cc:2:12: error: invalid use of type ‘void’ in parameter declaration
2 | void foo2 (void, int){}
  |^~~~

Apparently, "void" can be used in parameter declaration like line 1, but GCC
emits the ambiguity message on it. The output information conflicts with valid
grammar, so I guess users might be confused with this diagnostic.

I think clang handles better in this case

$clang++ -c test.cc
test.cc:2:11: error: 'void' must be the first and only parameter if specified
void foo2 (void, int){}
  ^
1 error generated.

Thanks,
Haoxin

[Bug c++/96115] Char literal, decays to a pointer when passed to function pointer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-08
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c++/19538] [DR 407] Bogus diagnostic for typedef name in elaborated type specifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|accepts-invalid, diagnostic |rejects-valid
 Status|SUSPENDED   |NEW
   Last reconfirmed|2005-10-02 21:02:16 |2020-7-8
Summary|[DR 407] Missing diagnostic |[DR 407] Bogus diagnostic
   |for typedef name in |for typedef name in
   |elaborated type specifier   |elaborated type specifier

--- Comment #4 from Jonathan Wakely  ---
Un-suspending, and changing from accepts-invalid to rejects-valid.

Both [1] and [2] are valid now and should be accepted.

[Bug c++/46206] using typedef-name error with typedef name hiding struct name

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=19538
   Keywords||rejects-valid

--- Comment #11 from Jonathan Wakely  ---
(In reply to Nathan Keynes from comment #0)
> but accepts many similar examples, including:
> class Foo
> {
> bool a, b, c;
> typedef struct Bar { } Bar;
> virtual void foo(void) {
> struct Bar bar;
> }
> };

That is no longer accepted, since r252005. So the difference was possibly a
bug, which got fixed, and now we consistently reject both, but ...

> I'm uncertain if this is strictly legal or not per the standard, but it
> doesn't seem to make sense to accept one of these cases but not the other.

It was made legal by https://wg21.link/cwg407 (c.f. PR 19538). Both examples
should compile.

[Bug c++/81836] ill-formed qualified name not diagnosed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|diagnostic  |
   Last reconfirmed|2017-08-21 00:00:00 |2020-7-8

--- Comment #3 from Jonathan Wakely  ---
(In reply to Eric Gallager from comment #2)
> cc-ing diagnostics maintainers

This is not a problem with a diagnostic, the diagnostic is just missing. That's
accepts-invalid.

[Bug c++/86709] 'short type-name' is invalid

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||haoxintu at gmail dot com

--- Comment #4 from Jonathan Wakely  ---
*** Bug 96118 has been marked as a duplicate of this bug. ***

[Bug c++/96118] GCC accepts invalid combination of two type specifiers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Jonathan Wakely  ---
It's PR 86709 (which was also found by fuzz testers comparing the results of
different compilers, maybe you should collaborate).

There's a diagnostic with -Wpedantic

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

[Bug c++/79815] gcc does not implement C++ standard 7.1.7.4.1 p5 correctly.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86709
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-08

[Bug c++/96121] New: Uninitialized variable copying not diagnosed

[antoshkka at gmail dot com]

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

Bug ID: 96121
   Summary: Uninitialized variable copying not diagnosed
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

struct A { A(); };
struct B { B(A); };

struct composed2 {
B b_;
A a_;
composed2() : b_(a_)  {}
};


GCC does not diagnose the uninitialized variable `a_` usage with -Wall and
-Wextra. Some other compiler do diagnose:

warning: field 'a_' is uninitialized when used here [-Wuninitialized]
composed2() : b_(a_)  {}
 ^

Godbolt playground: https://godbolt.org/z/AbqzjR

[Bug c++/96121] Uninitialized variable copying not diagnosed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-08

--- Comment #1 from Jonathan Wakely  ---
This is probably a dup of one of the many bugs about missing -Wuninitialized
diagnostics in mem-initializers.

[Bug c++/96120] Ambiguity diagnostic message of "invalid use of type 'void' in parameter declaration"

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #0)
> GCC might emit the ambiguity diagnostic message on it.

What does that mean?

[Bug c++/96120] Ambiguity diagnostic message of "invalid use of type 'void' in parameter declaration"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
GCC's diagnostic seems fine to me. Using 'void' as the type of a parameter is
invalid. There's a special case for (void) but that isn't relevant to your
declaration, which has two parameters.