[Bug tree-optimization/107226] [13 regression] r13-3219-g25413fdb2ac249 caused a lot of testcase failures

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug libgomp/107227] New: Compiler bug in private allocatable array in OpenACC compute statement

[shb at gatech dot edu via Gcc-bugs]

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

Bug ID: 107227
   Summary: Compiler bug in private allocatable array in OpenACC
compute statement
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shb at gatech dot edu
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The program below does not compile (nor does any variant of it involving
allocatable statements that I can think of). 
```
program main
integer :: i
real, allocatable :: arr(:)
allocate(arr(10))
!$acc parallel loop private(arr)
do i=1,10
arr=1.0
end do
end
```

The error is 
```
!$acc parallel loop private(arr)
  |^
internal compiler error: in expand_oacc_for, at omp-expand.cc:7660
```

A version of this suggested by Mat Colgrove also does not work:
```
program main
integer :: i
real, allocatable :: arr(:)
allocate(arr(10))
!$acc parallel loop private(arr(1:10)
do i=1,10
arr=1.0
end do
end
```

with error

```

5 | !$acc parallel loop private(arr(1:10))
  |1
Error: Syntax error in OpenMP variable list at (1)
```

These appear to be ICE compiler bugs as they are permitted by quite old OpenaCC
standards (and are seemingly typical use cases of OpenACC in Fortran). nvhpc
compilers work fine for this. 

The compile statement is 
`gfortran -foffload-options=-march=gfx90a -fopenacc test.f90`
with offloading onto an AMD MI210.

[Bug tree-optimization/107226] New: [13 regression] r13-3219-g25413fdb2ac249 caused a lot of testcase failures

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 107226
   Summary: [13 regression] r13-3219-g25413fdb2ac249 caused a lot
of testcase failures
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxbd 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxbd 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxbd 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxbq 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxbq 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxbq 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxbw 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxbw 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxbw 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxdq 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxdq 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxdq 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxwd 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxwd 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxwd 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxwq 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxwq 2
FAIL: gcc.target/i386/pr92658-avx2-2.c scan-assembler-times pmovsxwq 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxbd 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxbd 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxbd 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxbq 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxbq 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxbq 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxbw 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxbw 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxbw 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxdq 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxdq 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxdq 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxwd 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxwd 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxwd 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxwq 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxwq 2
FAIL: gcc.target/i386/pr92658-avx2.c scan-assembler-times pmovzxwq 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxbd 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxbd 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxbd 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxbq 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxbq 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxbq 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxbw 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxbw 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxbw 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxdq 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxdq 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxdq 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxwd 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxwd 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxwd 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxwq 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxwq 2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxwq 2
FAIL: gcc.target/i386/pr92658-avx512bw.c scan-assembler-times pmovzxbd 2
FAIL: gcc.target/i386/pr92658-avx512bw.c scan-assembler-times pmovzxbd 2
FAIL: gcc.target/i386/pr92658-avx512bw.c scan-assembler-times pmovzxbd 2
FAIL: gcc.target/i386/pr92658-avx512bw.c scan-assembler-times pmovzxbq 2
FAIL: gcc.target/i386/pr92658-avx512bw.c scan-assembler-times pmovzxbq 2
FAIL: gcc.target/i386/pr92658-avx512bw.c scan-assembler-times pmovzxbq 2
FAIL: 

[Bug testsuite/107220] [13 regression] gcc.dg/tree-ssa/forwprop-19.c fails after r13-3212-gb88adba751da63

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||admin at levyhsu dot com,
   ||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
Yes, we're working on this.

[Bug analyzer/107225] FP with -Wanalyzer-mismatching-deallocation

[urs at akk dot org via Gcc-bugs]

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

--- Comment #1 from urs at akk dot org ---
Created attachment 53694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53694=edit
reduced test case for FP with -fanalyzer (-Wanalyzer-mismatching-deallocation,
-Wanalyzer-file-leak)

[Bug analyzer/107225] New: FP with -Wanalyzer-mismatching-deallocation

[urs at akk dot org via Gcc-bugs]

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

Bug ID: 107225
   Summary: FP with -Wanalyzer-mismatching-deallocation
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: urs at akk dot org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

gcc build from git @ ab332cd78d083edb2fddaa3c02578cafade12725
with
configure --program-suffix=-13 --enable-languages=c,lto --enable-lto
--disable-multilib
make -j 4 BOOT_CFLAGS='-pipe -O0 -w' bootstrap

on x86_64-pc-linux-gnu (Intel(R) Core(TM) i7-6700T); Ubuntu 22.04.1 LTS; GLIBC
2.35-0ubuntu3.1

The somewhat reduced testcase shows (besides other stuff) a false positive with
gcc-13 -v -save-temps -freport-bug -g -O2 -Wextra -Wpedantic -pipe -Wall
-Winline -Wshadow -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wbad-function-cast -Wnested-externs -Wcast-align
-Wpointer-arith -Waggregate-return -Wcast-qual -Wwrite-strings -Wundef -Wpacked
-Wfloat-equal -Wunused-macros -Wold-style-definition -Winit-self
-Wmissing-include-dirs -Wlogical-op -Wjump-misses-init -Wformat=2
-Wshift-overflow=2 -Wnull-dereference -Wduplicated-cond -Walloc-zero -Walloca
-Wstringop-overflow=2 -Wduplicated-branches -Wno-format-nonliteral
-Wno-stringop-truncation -Wno-format-truncation -fanalyzer -c fp.c -o fp.o


fp.c:83:25: warning: ‘fp’ should have been deallocated with ‘fclose’ but was
deallocated with ‘pclose’ [CWE-762] [-Wanalyzer-mismatching-deallocation]
   83 | pclose(fp);
  | ^~

looks like the analyzer doesn't notice that it took the false branch in line 51
and thus has to take the false branch in line 82 again

[Bug libfortran/107223] GCC 12.2 fails compilation on Linux PowerPC In function 'bessel_jn_r17':

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-10-11
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
What configure options did you pass?
How did you do the build?

[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
Note -Og enables -funreachable-traps which is why the ones with -O1
-funreachable-traps are duplicates of this bug too.

[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||andres at anarazel dot de

--- Comment #4 from Andrew Pinski  ---
*** Bug 107224 has been marked as a duplicate of this bug. ***

[Bug ipa/107224] [13 Regression] ICE: verify_cgraph_node failed with -Og

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
And that is a dup of bug 106061.

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

[Bug ipa/107224] [13 Regression] ICE: verify_cgraph_node failed with -Og

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
The full ICE is:
: In function 'dataBeginPlaceToPage_maxOldItem':
:6:3: error: edge points to wrong declaration:
6 |   ItemPointerSet(dataBeginPlaceToPage_maxOldItem);
  |   ^~~
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f6525ddd690
arg-types >>
volatile nothrow public external built-in decl_6 QI :0:0
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_TRAP context
>
attributes 
chain 
chain 
chain  chain
>
 Instead of: 
unit-size 
align:32 warn_if_not_align:0 symtab:636507872 alias-set -1
canonical-type 0x7f6525dcd5e8 precision:32 min  max 
pointer_to_this >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f6525dda9d8
pointer_to_this >
addressable used public external decl_2 decl_5 QI :3:5 align:8
warn_if_not_align:0 chain >
ItemPointerSet/0 (ItemPointerSet)
  Type: function definition analyzed
  Visibility: semantic_interposition external public
  References: 
  Referring: 
  Function ItemPointerSet/0 is inline copy in dataBeginPlaceToPage_maxOldItem/1
  Availability: available
  Function flags: body
  Called by: dataBeginPlaceToPage_maxOldItem/1 (inlined) 
  Calls: __builtin_trap/3 (0 (precise),1.00 per call) 
during GIMPLE pass: einline
:6:3: internal compiler error: verify_cgraph_node failed
0x204ebde internal_error(char const*, ...)
???:0
0xb69ba7 cgraph_node::verify_node()
???:0
0xb57e0c symtab_node::verify()
???:0
0x10cc531 optimize_inline_calls(tree_node*)
???:0
0x1eb22d6 early_inliner(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
ASM generation compiler returned: 1
: In function 'dataBeginPlaceToPage_maxOldItem':
:6:3: error: edge points to wrong declaration:
6 |   ItemPointerSet(dataBeginPlaceToPage_maxOldItem);
  |   ^~~
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f568b587690
arg-types >>
volatile nothrow public external built-in decl_6 QI :0:0
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_TRAP context
>
attributes 
chain 
chain 
chain  chain
>
 Instead of: 
unit-size 
align:32 warn_if_not_align:0 symtab:-1955924256 alias-set -1
canonical-type 0x7f568b5775e8 precision:32 min  max 
pointer_to_this >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f568b5849d8
pointer_to_this >
addressable used public external decl_2 decl_5 QI :3:5 align:8
warn_if_not_align:0 chain >
ItemPointerSet/0 (ItemPointerSet)
  Type: function definition analyzed
  Visibility: semantic_interposition external public
  References: 
  Referring: 
  Function ItemPointerSet/0 is inline copy in dataBeginPlaceToPage_maxOldItem/1
  Availability: available
  Function flags: body
  Called by: dataBeginPlaceToPage_maxOldItem/1 (inlined) 
  Calls: __builtin_trap/3 (0 (precise),1.00 per call) 
during GIMPLE pass: einline
:6:3: internal compiler error: verify_cgraph_node failed
0x204ebde internal_error(char const*, ...)
???:0
0xb69ba7 cgraph_node::verify_node()
???:0
0xb57e0c symtab_node::verify()
???:0
0x10cc531 optimize_inline_calls(tree_node*)
???:0
0x1eb22d6 early_inliner(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Execution build compiler returned: 1

[Bug ipa/107224] [13 Regression] ICE: verify_cgraph_node failed with -Og

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE: verify_cgraph_node |[13 Regression] ICE:
   |failed with -Og |verify_cgraph_node failed
   ||with -Og
   Target Milestone|--- |13.0

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #18 from H.J. Lu  ---
(In reply to Segher Boessenkool from comment #16)
> Hi Roger,
> 
> (In reply to Roger Sayle from comment #15)
> > Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> > operations also legitimately set and/or use MODE_CC, often in a parallel
> > with the primary operation.
> 
> *Any* MODE_CC setter sets the flags as-if from a compare.  This is what
> MODE_CC *is*.
> 
> Setting something as ne:CC and then using it as somethingelse:CC has no
> defined meaning.

This

(parallel [
(set (reg:SI 97) 
(neg:SI (ltu:SI (reg:CCC 17 flags)
(const_int 0 [0]
(clobber (reg:CC 17 flags))
])

still won't work correctly if reg:CCC 17 flags is set by a compare of
2 known values.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #17 from H.J. Lu  ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to H.J. Lu from comment #13)
> > (In reply to Segher Boessenkool from comment #12)
> > > 
> > > To determine the semantics of this piece of RTL you need to see the 
> > > setter(s)
> > > of reg 17 feeding this use.  In this case, the setter was
> > >   (set (reg:CCC 17)
> > >(ne:CCC (reg:SI 82)
> > >(const_int 0 [0])))
> > > which has no meaning for a use that uses "ltu".
> > 
> > What should a valid setter look like?  It should set reg 17 in CCC mode if
> > reg 82 in SI mode isn't 0.
> 
> CCCmode can only represent the result of a comparison, like any other MODE_CC
> thing.  The i386 CCCmode means only the carry bit can be used for this, so
> you
> beed to do an unsigned comparison against (const_int 1).  This will end up
> with
> the opposite polarity of what you said I guess, you need "geu" instead?

Since it checks if the input register is 0, compare against (const_int 1)
won't work here.

[Bug c/107224] New: ICE: verify_cgraph_node failed with -Og

[andres at anarazel dot de via Gcc-bugs]

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

Bug ID: 107224
   Summary: ICE: verify_cgraph_node failed with -Og
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andres at anarazel dot de
  Target Milestone: ---

Created attachment 53693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53693=edit
reproducer

Hi,

When building postgres with gcc 13 I get a lot of ICEs. I reproduced this on
today's master (53955284c03) and reduced one of the failing files with cvise.

$ ~/build/gcc-master/install/bin/gcc -Og -c gindatapage.i -o gindatapage.o
[bunch of warnings due to cvise]
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f3b8de315e8
arg-types >>
volatile nothrow public external built-in decl_6 QI :0:0
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_TRAP context

attributes 
chain 
chain 
chain  chain
>
 Instead of: 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f3b8de215e8 precision:32 min  max

pointer_to_this >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f3b8de30930
pointer_to_this >
addressable used public external decl_2 decl_5 QI gindatapage.i:3:5 align:8
warn_if_not_align:0 chain >
ItemPointerSet/0 (ItemPointerSet)
  Type: function definition analyzed
  Visibility: semantic_interposition external public
  References: 
  Referring: 
  Function ItemPointerSet/0 is inline copy in dataBeginPlaceToPage_maxOldItem/1
  Availability: available
  Function flags: body
  Called by: dataBeginPlaceToPage_maxOldItem/1 (inlined) 
  Calls: __builtin_trap/3 (0 (precise),1.00 per call) 
during GIMPLE pass: einline
gindatapage.i:6:3: internal compiler error: verify_cgraph_node failed
0xa35b90 cgraph_node::verify_node()
/home/andres/src/gcc/gcc/cgraph.cc:3881
0xa25804 symtab_node::verify()
/home/andres/src/gcc/gcc/symtab.cc:1360
0xf5b0da expand_call_inline
/home/andres/src/gcc/gcc/tree-inline.cc:4912
0xf5dbd6 gimple_expand_calls_inline
/home/andres/src/gcc/gcc/tree-inline.cc:5318
0xf5dbd6 optimize_inline_calls(tree_node*)
/home/andres/src/gcc/gcc/tree-inline.cc:5490
0x1d277ed early_inliner(function*)
/home/andres/src/gcc/gcc/ipa-inline.cc:3038

[Bug fortran/107223] New: GCC 12.2 fails compilation on Linux PowerPC In function 'bessel_jn_r17':

[skoerner at nvidia dot com via Gcc-bugs]

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

Bug ID: 107223
   Summary: GCC 12.2 fails compilation on Linux PowerPC In
function 'bessel_jn_r17':
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skoerner at nvidia dot com
  Target Milestone: ---

../.././libgfortran/generated/bessel_r17.c: In function 'bessel_jn_r17':
../.././libgfortran/generated/bessel_r17.c:83:20: error: implicit declaration
of function 'jnq'; did you mean 'jnl'? [-Werror=implicit-function-declaration]
   83 |   last1 = MATHFUNC(jn) (n2, x);
  |^~
../.././libgfortran/generated/bessel_r17.c:34:28: note: in definition of macro
'MATHFUNC'
   34 | #define MATHFUNC(funcname) funcname ## q
  |^~~~
../.././libgfortran/generated/bessel_r17.c: In function 'bessel_yn_r17':
../.././libgfortran/generated/bessel_r17.c:153:20: error: implicit declaration
of function 'ynq'; did you mean 'ynl'? [-Werror=implicit-function-declaration]
  153 |   last1 = MATHFUNC(yn) (n1, x);
  |^~
../.././libgfortran/generated/bessel_r17.c:34:28: note: in definition of macro
'MATHFUNC'
   34 | #define MATHFUNC(funcname) funcname ## q
  |^~~~


4.14.0-115.el7a.ppc64le RHEL 7.6

[Bug fortran/107215] ICE in gfc_real2real and gfc_complex2complex

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed for gcc-13.  Closing.

Thanks for the report!

[Bug fortran/107215] ICE in gfc_real2real and gfc_complex2complex

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:53955284c031a17e6e49e730ef8947fe557ff35e

commit r13-3238-g53955284c031a17e6e49e730ef8947fe557ff35e
Author: Harald Anlauf 
Date:   Tue Oct 11 20:37:42 2022 +0200

Fortran: check types of source expressions before conversion [PR107215]

gcc/fortran/ChangeLog:

PR fortran/107215
* arith.cc (gfc_int2int): Check validity of type of source expr.
(gfc_int2real): Likewise.
(gfc_int2complex): Likewise.
(gfc_real2int): Likewise.
(gfc_real2real): Likewise.
(gfc_complex2int): Likewise.
(gfc_complex2real): Likewise.
(gfc_complex2complex): Likewise.
(gfc_log2log): Likewise.
(gfc_log2int): Likewise.
(gfc_int2log): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/107215
* gfortran.dg/pr107215.f90: New test.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Segher Boessenkool  ---
Hi Roger,

(In reply to Roger Sayle from comment #15)
> Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> operations also legitimately set and/or use MODE_CC, often in a parallel
> with the primary operation.

*Any* MODE_CC setter sets the flags as-if from a compare.  This is what
MODE_CC *is*.

Setting something as ne:CC and then using it as somethingelse:CC has no
defined meaning.

[Bug fortran/107217] ICE in gfc_arith_times, at fortran/arith.cc:715/704

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058328.html

[Bug c++/107222] const qualifier appears in mangled NTTP value when the original object is so qualified

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-11
 Status|UNCONFIRMED |NEW
   Keywords||ABI, wrong-code

--- Comment #1 from Andrew Pinski  ---
Here is one which shows the issue at link time.
This should link and run.
One testcase:
```
struct A { int i; };
union Y { A a; };
constexpr Y make_y(const A a) { return {a}; }
template struct q { };
template constexpr q make_q() { return {}; }
template void print();
template<> void print{}>()
{
}
int main() {
  constexpr q x = make_q();
  constexpr q x1 = make_q<(Y){.a={1}}>();
  print();
  print();
}
```
Another one:
```
struct A { int i; };
union Y { A a; };
constexpr Y make_y(const A a) { return {a}; }
template struct q { };
template constexpr q make_q() { return {}; }
void print(q<(Y){.a={1}}> a)
{

}
void print(...);
int main() {
  constexpr q x = make_q();
  constexpr q x1 = make_q<(Y){.a={1}}>();
  print(x);
  print(x1);
}
```
clang mangles both x and x1 the same ...

[Bug c/107197] valgrind error in function same_line_p during build

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #9 from Eugene Rozenfeld  ---
107193 was fixed by
https://gcc.gnu.org/g:80f414e6d73f9f1683f93d83ce63a6a482e54bee

[Bug c++/107222] New: const qualifier appears in mangled NTTP value when the original object is so qualified

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 107222
   Summary: const qualifier appears in mangled NTTP value when the
original object is so qualified
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://compiler-explorer.com/z/63f9sxnec.

```C++
struct A { int i; };
union Y { A a; };
constexpr Y make_y(const A a) { return {a}; }
template struct q { };
template constexpr q make_q() { return {}; }
template void print();
int main() {
  constexpr q x = make_q();
  print();
  // +x;
}
```

```
main:
sub rsp, 8
callvoid print{}>()
xor eax, eax
add rsp, 8
ret
```

Alternatively, when uncommenting `+x;`:
```
: In function 'int main()':
:10:3: error: no match for 'operator+' (operand type is 'const
q')
   10 |   +x;
  |   ^~
```

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #15 from Roger Sayle  ---
Hi HJ (and Segher),
The i386's *negsi_ccc_1 pattern fully models the flags setting behaviour of the
x86's neg instruction.  neg %eax, in addition to setting %eax to -%eax, will
clear the carry flag if %eax is zero, and set it for all other values of %eax. 
Hence, this pattern is a useful mechanism for setting the carry flag to a known
value from a scalar integer register.  For example, it's used in the expansion
of __builtin_add_with_carry (sp?).

The *x86_movsicc_0_m1_neg instruction does the reverse.  The sbc %eax,%eax
instruction (subtract with carry) will place the value 0 in %eax if the carry
flag is clear, and the value -1 in %eax if the carry flag is set (independent
of whatever value was in %eax before the instruction).

Understanding these patterns is perhaps a little easier with a little more
context.  For example,
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598058.html describes
efforts to add support for x86's stc (set carry flag) and clc (clear carry
flag) instructions.  I've a similar patch for "cmc" (complement carry flag) but
all of these are blocked by the simplify-rtx issue
underlying PR 107172, that MODE_CC requires special care and/or backend
specific support to interpret.

Yes, a COMPARE rtx can be used to set various flags on x86, but many other
operations also legitimately set and/or use MODE_CC, often in a parallel with
the primary operation.

[Bug fortran/107217] ICE in gfc_arith_times, at fortran/arith.cc:715/704

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-10-11
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

Testing the following patch:

diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 9e079e42995..c224cd30a54 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -692,6 +692,9 @@ gfc_arith_times (gfc_expr *op1, gfc_expr *op2, gfc_expr
**resultp)
   gfc_expr *result;
   arith rc;

+  if (op1->ts.type != op2->ts.type)
+return ARITH_INVALID_TYPE;
+
   result = gfc_get_constant_expr (op1->ts.type, op1->ts.kind, >where);

   switch (op1->ts.type)
@@ -712,7 +715,8 @@ gfc_arith_times (gfc_expr *op1, gfc_expr *op2, gfc_expr
**resultp)
   break;

 default:
-  gfc_internal_error ("gfc_arith_times(): Bad basic type");
+  gfc_free_expr (result);
+  return ARITH_INVALID_TYPE;
 }

   rc = gfc_range_check (result);

[Bug bootstrap/107221] [13 Regression] libstdc++ EH no matching function __gnu_cxx::__scoped_lock::__scoped_lock

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:23c3cbaed36f6d2f3a7a64f6ebda69329723514b

commit r13-3237-g23c3cbaed36f6d2f3a7a64f6ebda69329723514b
Author: Jonathan Wakely 
Date:   Tue Oct 11 20:19:08 2022 +0100

libstdc++: Fix bootstrap for --disable-threads build [PR107221]

The __scoped_lock type should be used unqualified so that we always
refer to pool::__scoped_lock, which might be the dummy fallback
implementation.

The __mutex and __scoped_lock types in  already work
fine without __GTHREADS being defined, but that header isn't included at
all unless _GLIBCXX_HOSTED != 0. The fallback implementation should be
used for ! _GLIBCXX_HOSTED instead of for !defined __GTHREADS.

libstdc++-v3/ChangeLog:

PR bootstrap/107221
* libsupc++/eh_alloc.cc (pool): Change preprocessor condition
for using __mutex from __GTHREADS to _GLIBCXX_HOSTED.
(pool::allocate): Remove namespace qualification to use
pool::__scoped_lock instead of __gnu_cxx::__scoped_lock.

[Bug bootstrap/107221] [13 Regression] libstdc++ EH no matching function __gnu_cxx::__scoped_lock::__scoped_lock

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Jonathan Wakely  ---
Same place it's always been defined, in gthr.h which is included by


And every other header includes  i.e. all of these:

#include// std::exception
#include  // std::terminate
#include  // std::malloc, std::free, std::strtoul
#include  // INT_MAX
#include  // std::less
#include "unwind-cxx.h"
#if _GLIBCXX_HOSTED
# include // std::string_view
# include // std::strchr, std::memset
# include   // __gnu_cxx::__mutex, __gnu_cxx::__scoped_lock
#endif

That's why I removed the unnecessary initial #include of it.


This should fix it:

--- a/libstdc++-v3/libsupc++/eh_alloc.cc
+++ b/libstdc++-v3/libsupc++/eh_alloc.cc
@@ -236,7 +236,7 @@ namespace

   void *pool::allocate (std::size_t size) noexcept
 {
-  __gnu_cxx::__scoped_lock sentry(emergency_mutex);
+  __scoped_lock sentry(emergency_mutex);
   // We need an additional size_t member plus the padding to
   // ensure proper alignment of data.
   size += offsetof (allocated_entry, data);

[Bug bootstrap/107221] [13 Regression] libstdc++ EH no matching function __gnu_cxx::__scoped_lock::__scoped_lock

[dje at gcc dot gnu.org via Gcc-bugs]

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-11
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Where is __GTHREADS defined now?

-#include 

...

+#ifdef __GTHREADS
   // A single mutex controlling emergency allocations.
   __gnu_cxx::__mutex emergency_mutex;
+  using __scoped_lock = __gnu_cxx::__scoped_lock;
+#else
+  int emergency_mutex = 0;
+  struct __scoped_lock { explicit __scoped_lock(int) { } };
+#endif

[Bug c++/100134] [modules] ICE when using a vector in a module

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:9736a42e1fb8df30d72cf28594d9046bf50200c1

commit r13-3236-g9736a42e1fb8df30d72cf28594d9046bf50200c1
Author: Patrick Palka 
Date:   Tue Oct 11 15:02:23 2022 -0400

c++ modules: ICE with templated friend and std namespace [PR100134]

The function depset::hash::add_binding_entity has an assert verifying
that if a namespace contains an exported entity, then the namespace must
have been opened in the module purview:

  if (data->hash->add_namespace_entities (decl, data->partitions))
{
  /* It contains an exported thing, so it is exported.  */
  gcc_checking_assert (DECL_MODULE_PURVIEW_P (decl));
  DECL_MODULE_EXPORT_P (decl) = true;
}

We're tripping over this assert in the below testcase because by
instantiating and exporting std::A, we in turn define and export the
hidden friend std::f(A) without ever having opened the enclosing
namespace std within the module purview, and thus DECL_MODULE_PURVIEW_P
for std is false.

It's important that the enclosing namespace is std here: if we use
a different namespace then the ICE disappears.  This probably has
something to do with us predefining std via push_namespace from
cxx_init_decl_processing (which makes it look like we've opened it
within the TU), whereas with another namespace we would instead lazily
create its NAMESPACE_DECL from add_imported_namespace.

Since templated friend functions are special in that they give us a way
to introduce a namespace-scope function without having to explicitly
open the namespace, this patch proposes to fix this ICE by propagating
DECL_MODULE_PURVIEW_P from the introduced function to the enclosing
namespace during tsubst_friend_function.

PR c++/100134

gcc/cp/ChangeLog:

* pt.cc (tsubst_friend_function): Propagate DECL_MODULE_PURVIEW_P
from the introduced namespace-scope function to the namespace.

gcc/testsuite/ChangeLog:

* g++.dg/modules/tpl-friend-8_a.H: New test.
* g++.dg/modules/tpl-friend-8_b.C: New test.

[Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:2ceb4d531a303f3e70d8bb218c8759e6c0688f62

commit r13-3235-g2ceb4d531a303f3e70d8bb218c8759e6c0688f62
Author: Patrick Palka 
Date:   Tue Oct 11 15:02:01 2022 -0400

c++ modules: lazy loading from within template [PR99377]

Here when lazily loading the binding for f due to its first use from the
template g, processing_template_decl is set which causes the call to
note_vague_linkage_fn from module_state::read_cluster to have no effect,
and thus we never push f onto deferred_fns and end up never emitting its
definition despite needing it.

The behavior of the lazy loading machinery shouldn't be sensitive to
whether we're inside a template, so to that end this patch makes us
clear processing_template_decl in the entrypoints lazy_load_binding and
lazy_load_pendings.

PR c++/99377

gcc/cp/ChangeLog:

* module.cc (lazy_load_binding): Clear processing_template_decl.
(lazy_load_pendings): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/modules/pr99377-2_a.C: New test.
* g++.dg/modules/pr99377-2_b.C: New test.

[Bug bootstrap/107221] New: [13 Regression] libstdc++ EH no matching function __gnu_cxx::__scoped_lock::__scoped_lock

[dje at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107221
   Summary: [13 Regression] libstdc++ EH no matching function
__gnu_cxx::__scoped_lock::__scoped_lock
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

The fix for PR68606 introduced references to
__gnu_cxx::__scoped_lock::__scoped_lock that are not always defined, causing a
bootstrap failure on AIX.

libtool: compile:  /tmp/GCC/./gcc/xgcc -B/tmp/GCC/./gcc/
-B/nasfarm/edelsohn/ins
tall/GCC/powerpc-ibm-aix7.2.5.0/bin/
-B/nasfarm/edelsohn/install/GCC/powerpc-ibm
-aix7.2.5.0/lib/ -isystem
/nasfarm/edelsohn/install/GCC/powerpc-ibm-aix7.2.5.0/i
nclude -isystem
/nasfarm/edelsohn/install/GCC/powerpc-ibm-aix7.2.5.0/sys-include
 -fno-checking -DHAVE_CONFIG_H -I..
-I/nasfarm/edelsohn/src/src/libstdc++-v3/../
libiberty -I/nasfarm/edelsohn/src/src/libstdc++-v3/../include -D_GLIBCXX_SHARED 
-I/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/powerpc-ibm-aix7.2.5.0
-I/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include
-I/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++
-I/nasfarm/edelsohn/install/include -I/nasfarm/edelsohn/install/include -g -O2
-DIN_GLIBCPP_V3 -Wno-error -c cp-demangle.c  -fPIC -DPIC -o cp-demangle.o
/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++/eh_alloc.cc: In member
function 'void* {anonymous}::pool::allocate(std::size_t)':
/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++/eh_alloc.cc:239:54: error: no
matching function for call to '__gnu_cxx::__scoped_lock::__scoped_lock(int&)'
  239 |   __gnu_cxx::__scoped_lock sentry(emergency_mutex);
  |  ^
In file included from
/nasfarm/edelsohn/src/src/libstdc++-v3/libsupc++/eh_alloc.cc:37:
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/ext/concurrence.h:240:14:
note: candidate: '__gnu_cxx::__scoped_lock::__scoped_lock(__mutex_type&)'
  240 | explicit __scoped_lock(__mutex_type& __name) : _M_device(__name)
  |  ^
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/ext/concurrence.h:240:42:
note:   no known conversion for argument 1 from 'int' to
'__gnu_cxx::__scoped_lock::__mutex_type&'
  240 | explicit __scoped_lock(__mutex_type& __name) : _M_device(__name)
  |~~^~
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/ext/concurrence.h:236:5:
note: candidate: '__gnu_cxx::__scoped_lock::__scoped_lock(const
__gnu_cxx::__scoped_lock&)'
  236 | __scoped_lock(const __scoped_lock&);
  | ^
/tmp/GCC/powerpc-ibm-aix7.2.5.0/libstdc++-v3/include/ext/concurrence.h:236:19:
note:   no known conversion for argument 1 from 'int' to 'const
__gnu_cxx::__scoped_lock&'
  236 | __scoped_lock(const __scoped_lock&);
  |   ^~~~
make[5]: *** [Makefile:778: eh_alloc.lo] Error 1

[Bug fortran/107219] ICE in reduce_unary, at fortran/arith.cc:1290

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93483
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-11
 Ever confirmed|0   |1
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

The following example from pr93483 has the same issue:

  print *, +[ real :: (1) ]
end

[Bug c++/104433] [modules] Importing and using std::make_shared causes linker errors

[lhlaurini at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from Luiz Henrique Laurini  ---
Thank you for the fix. The test case seems to be working as expected now.

However, the original code

import ;

int main()
{
std::make_shared();
}

now causes an internal compiler error:

during IPA pass: visibility
main.cpp:6:1: internal compiler error: in function_and_variable_visibility, at
ipa-visibility.cc:712
6 | }
  | ^
0x236019e internal_error(char const*, ...)
???:0
0xaa1f68 fancy_abort(char const*, int, char const*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Godbolt link (using gcc trunk): https://godbolt.org/z/bMYYvWd8e

Should I report a new bug?

[Bug fortran/107215] ICE in gfc_real2real and gfc_complex2complex

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058326.html

[Bug testsuite/107220] New: [13 regression] gcc.dg/tree-ssa/forwprop-19.c fails after r13-3212-gb88adba751da63

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107220
   Summary: [13 regression] gcc.dg/tree-ssa/forwprop-19.c fails
after r13-3212-gb88adba751da63
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:b88adba751da635c6f0c353c5bc51bbe2ecf4c89, r13-3212-gb88adba751da63
make  -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/forwprop-19.c"
FAIL: gcc.dg/tree-ssa/forwprop-19.c scan-tree-dump-not forwprop1
"VEC_PERM_EXPR"
# of expected passes1
# of unexpected failures1

commit b88adba751da635c6f0c353c5bc51bbe2ecf4c89 (HEAD, refs/bisect/bad)
Author: Liwei Xu 
Date:   Fri Sep 23 13:46:02 2022 +0800

Optimize nested permutation to single VEC_PERM_EXPR [PR54346]

[Bug c++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Well, why don't I go ahead and post it.

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Segher Boessenkool  ---
(In reply to H.J. Lu from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> > 
> > To determine the semantics of this piece of RTL you need to see the 
> > setter(s)
> > of reg 17 feeding this use.  In this case, the setter was
> >   (set (reg:CCC 17)
> >(ne:CCC (reg:SI 82)
> >(const_int 0 [0])))
> > which has no meaning for a use that uses "ltu".
> 
> What should a valid setter look like?  It should set reg 17 in CCC mode if
> reg 82 in SI mode isn't 0.

CCCmode can only represent the result of a comparison, like any other MODE_CC
thing.  The i386 CCCmode means only the carry bit can be used for this, so you
beed to do an unsigned comparison against (const_int 1).  This will end up with
the opposite polarity of what you said I guess, you need "geu" instead?

[Bug fortran/107215] ICE in gfc_real2real and gfc_complex2complex

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 53692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53692=edit
Patch

Check type of source expr before conversion.

[Bug c++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
I think the problem is that since r12-8066, in cxx_eval_vec_init we perform
expand_vec_init_expr while processing the default argument, at which point
start_preparsed_function hasn't yet set current_function_decl. 
expand_vec_init_expr then leads to maybe_splice_retval_cleanup which checks
DECL_CONSTRUCTOR_P (current_function_decl) without checking that
current_function_decl is non-null first.  It seems correct that
current_function_decl is null at that point, so the fix should be just:

--- a/gcc/cp/except.cc
+++ b/gcc/cp/except.cc
@@ -1327,6 +1327,7 @@ maybe_splice_retval_cleanup (tree compound_stmt)
&& current_binding_level->level_chain->kind == sk_function_parms);

   if ((function_body || current_binding_level->kind == sk_try)
+  && current_function_decl
   && !DECL_CONSTRUCTOR_P (current_function_decl)
   && !DECL_DESTRUCTOR_P (current_function_decl)
   && current_retval_sentinel)

[Bug fortran/107215] ICE in gfc_real2real and gfc_complex2complex

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-10-11

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  The fix is straightforward after the fix for pr107000.
(Code audit).

[Bug target/107201] [avr] -nodevicelib not working for devices -mmcu=avr...

[gjl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 53691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53691=edit
pr107201.diff: Proposed patch.

This proposed patch (effectively) sets macro X_NODEVLIB to "" in all of
./config/avr/driver-avr.cc.

-nodevicelib is a known driver option from avr.opt, so there should be no need
to explicitly remove it by hand by means of %

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #13 from H.J. Lu  ---
(In reply to Segher Boessenkool from comment #12)
> 
> To determine the semantics of this piece of RTL you need to see the setter(s)
> of reg 17 feeding this use.  In this case, the setter was
>   (set (reg:CCC 17)
>(ne:CCC (reg:SI 82)
>(const_int 0 [0])))
> which has no meaning for a use that uses "ltu".

What should a valid setter look like?  It should set reg 17 in CCC mode if
reg 82 in SI mode isn't 0.

[Bug fortran/107219] New: ICE in reduce_unary, at fortran/arith.cc:1290

[gscfq--- via Gcc-bugs]

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

Bug ID: 107219
   Summary: ICE in reduce_unary, at fortran/arith.cc:1290
   Product: gcc
   Version: 13.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 :
(in addition to pr93483_c2_first_print)


$ cat z1.f90
program p
   print *, -[real :: [(1)]]
   print *, +[real :: [-(1)]]
   print *, -[real :: [[(1)]]]
end


$ gfortran-13-20221009 -c z1.f90
f951: internal compiler error: Segmentation fault
0xf3feef crash_signal
../../gcc/toplev.cc:314
0x7becaf reduce_unary
../../gcc/fortran/arith.cc:1290
0x7bec7f reduce_unary
../../gcc/fortran/arith.cc:1277
0x7bec7f reduce_unary
../../gcc/fortran/arith.cc:1277
0x7bf408 eval_intrinsic
../../gcc/fortran/arith.cc:1652
0x832374 match_level_2
../../gcc/fortran/matchexp.cc:490
0x832392 match_level_3
../../gcc/fortran/matchexp.cc:551
0x832484 match_level_4
../../gcc/fortran/matchexp.cc:599
0x832484 match_and_operand
../../gcc/fortran/matchexp.cc:693
0x832672 match_or_operand
../../gcc/fortran/matchexp.cc:722
0x832742 match_equiv_operand
../../gcc/fortran/matchexp.cc:765
0x832814 match_level_5
../../gcc/fortran/matchexp.cc:811
0x831be1 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.cc:870
0x8192d9 match_io_element
../../gcc/fortran/io.cc:3668
0x81bc0a match_io_list
../../gcc/fortran/io.cc:3716
0x81c00e match_io
../../gcc/fortran/io.cc:4394
0x81fb0a gfc_match_print()
../../gcc/fortran/io.cc:4450
0x851e41 match_word
../../gcc/fortran/parse.cc:67
0x857aa3 decode_statement
../../gcc/fortran/parse.cc:539
0x857eda next_free
../../gcc/fortran/parse.cc:1402

[Bug c++/107218] New: [13 Regression] ICE in cp_gimplify_init_expr, at cp/cp-gimplify.cc:253

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107218
   Summary: [13 Regression] ICE in cp_gimplify_init_expr, at
cp/cp-gimplify.cc:253
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++ 13.0.0 20221009 snapshot (g:e95e91eccd022a4a3a86da2749809fbad9afd20e) ICEs
when compiling the following testcase, reduced from
clang/testsuite/SemaCXX/cxx2a-consteval.cpp from the clang 15.0.1 test suite,
w/ -std=c++20 -O1:

namespace std {
template 
struct remove_reference {
  using type = T;
};

template 
constexpr typename std::remove_reference::type &&
move (T &) noexcept
{
  return static_cast::type &&> (t);
}
}

consteval int
f_eval ()
{
  return 0;
}

struct Copy {
  int (*ptr) ();

  constexpr Copy (int (*p) () = nullptr) : ptr (p)
  {
  }
};

Copy *
test ()
{
  return new Copy (std::move (Copy (_eval)));
}

% g++-13 -std=c++20 -O1 -c rc4hkfes.cpp
rc4hkfes.cpp: In function 'Copy* test()':
rc4hkfes.cpp:32:37: error: taking address of an immediate function 'consteval
int f_eval()'
   32 |   return new Copy (std::move (Copy (_eval)));
  | ^~~
rc4hkfes.cpp:32:46: internal compiler error: in cp_gimplify_init_expr, at
cp/cp-gimplify.cc:253
   32 |   return new Copy (std::move (Copy (_eval)));
  |  ^
0x6adbf7 cp_gimplify_init_expr
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/cp/cp-gimplify.cc:253
0x9eb5f7 cp_gimplify_expr(tree_node**, gimple**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/cp/cp-gimplify.cc:508
0xef9cce gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16237
0xf0c527 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:7187
0xf0c527 gimplify_compound_expr
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:6380
0xf0c5c9 gimplify_compound_expr
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:6378
0xf0db89 gimplify_modify_expr_rhs
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:5682
0xf0e316 gimplify_modify_expr
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:6076
0xefa661 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16328
0xefcf96 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:7187
0xf0b4fd gimplify_and_add(tree_node*, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:492
0xf0b4fd gimplify_return_expr
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:1680
0xefae1a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16590
0xefcf96 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:7187
0xefe7cc gimplify_cleanup_point_expr
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:6928
0xefb1e2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:16721
0xf1dfe2 gimplify_stmt(tree_node**, gimple**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:7187
0xf1dfe2 gimplify_body(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:17588
0xf1e46a gimplify_function_tree(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/gimplify.cc:17787
0xd39a97 cgraph_node::analyze()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221009/work/gcc-13-20221009/gcc/cgraphunit.cc:676

I suspect it can be a duplicate of PR107198, though.

[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

[gscfq--- via Gcc-bugs]

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

--- Comment #4 from G. Steinmetz  ---

Case from c0 works now :

$ gfortran-13-20221009 z1.f90 && ./a.out
   1.   2.
   1.   2.

[Bug fortran/107217] New: ICE in gfc_arith_times, at fortran/arith.cc:715/704

[gscfq--- via Gcc-bugs]

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

Bug ID: 107217
   Summary: ICE in gfc_arith_times, at fortran/arith.cc:715/704
   Product: gcc
   Version: 13.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
   print *, [real :: (['1'])] * 2
end

$ cat z2.f90
program p
   print *, 2 * [real :: (['1'])]
end


$ gfortran-13-20221009 -c z1.f90
f951: internal compiler error: gfc_arith_times(): Bad basic type
0x7f6c49 gfc_report_diagnostic
../../gcc/fortran/error.cc:883
0x7f87c7 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.cc:1503
0x7c0946 gfc_arith_times
../../gcc/fortran/arith.cc:715
0x7beef9 reduce_binary_ac
../../gcc/fortran/arith.cc:1317
0x7bef55 reduce_binary_ac
../../gcc/fortran/arith.cc:1321
0x7bf1a4 reduce_binary
../../gcc/fortran/arith.cc:1476
0x7bf5d2 eval_intrinsic
../../gcc/fortran/arith.cc:1654
0x83208c match_add_operand
../../gcc/fortran/matchexp.cc:392
0x83223c match_level_2
../../gcc/fortran/matchexp.cc:480
0x832392 match_level_3
../../gcc/fortran/matchexp.cc:551
0x832484 match_level_4
../../gcc/fortran/matchexp.cc:599
0x832484 match_and_operand
../../gcc/fortran/matchexp.cc:693
0x832672 match_or_operand
../../gcc/fortran/matchexp.cc:722
0x832742 match_equiv_operand
../../gcc/fortran/matchexp.cc:765
0x832814 match_level_5
../../gcc/fortran/matchexp.cc:811
0x831be1 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.cc:870
0x8192d9 match_io_element
../../gcc/fortran/io.cc:3668
0x81bc0a match_io_list
../../gcc/fortran/io.cc:3716
0x81c00e match_io
../../gcc/fortran/io.cc:4394
0x81fb0a gfc_match_print()
../../gcc/fortran/io.cc:4450

[Bug fortran/107216] ICE in reduce_binary_aa, at fortran/arith.cc:1427

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code,
   ||ice-on-valid-code

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


And some invalid examples :


$ cat zz1.f90
program p
   print *, [real :: 1, 2] * [real :: (1), +('1')]
end

$ cat zz2.f90
program p
   print *, [real :: (1), +('1')] * [real :: 1, 2]
end

$ cat zz3.f90
program p
   print *, [real :: 1, 2] * [real :: (1), +(.true.)]
end

$ cat zz4.f90
program p
   print *, [real :: (1), +(.true.)] * [real :: 1, 2]
end

[Bug fortran/107216] New: ICE in reduce_binary_aa, at fortran/arith.cc:1427

[gscfq--- via Gcc-bugs]

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

Bug ID: 107216
   Summary: ICE in reduce_binary_aa, at fortran/arith.cc:1427
   Product: gcc
   Version: 13.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 :
(valid examples)


$ cat z1.f90
program p
   print *, [real :: 1, 2] * [real :: 1, (2)]
end

$ cat z2.f90
program p
   print *, [real :: 1, (2)] * [real :: 1, 2]
end


$ gfortran-13-20221009 -c z1.f90
f951: internal compiler error: Segmentation fault
0xf3feef crash_signal
../../gcc/toplev.cc:314
0x1fe6c0c splay_tree_foreach
../../libiberty/splay-tree.c:577
0x7d85d4 gfc_constructor_copy(splay_tree_s*)
../../gcc/fortran/constructor.cc:104
0x7bf0a7 reduce_binary_aa
../../gcc/fortran/arith.cc:1427
0x7bf0a7 reduce_binary
../../gcc/fortran/arith.cc:1478
0x7bf0ec reduce_binary_aa
../../gcc/fortran/arith.cc:1437
0x7bf0ec reduce_binary
../../gcc/fortran/arith.cc:1478
0x7bf5d2 eval_intrinsic
../../gcc/fortran/arith.cc:1654
0x83208c match_add_operand
../../gcc/fortran/matchexp.cc:392
0x83223c match_level_2
../../gcc/fortran/matchexp.cc:480
0x832392 match_level_3
../../gcc/fortran/matchexp.cc:551
0x832484 match_level_4
../../gcc/fortran/matchexp.cc:599
0x832484 match_and_operand
../../gcc/fortran/matchexp.cc:693
0x832672 match_or_operand
../../gcc/fortran/matchexp.cc:722
0x832742 match_equiv_operand
../../gcc/fortran/matchexp.cc:765
0x832814 match_level_5
../../gcc/fortran/matchexp.cc:811
0x831be1 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.cc:870
0x8192d9 match_io_element
../../gcc/fortran/io.cc:3668
0x81bc0a match_io_list
../../gcc/fortran/io.cc:3716
0x81c00e match_io
../../gcc/fortran/io.cc:4394

[Bug fortran/107215] New: ICE in gfc_real2real and gfc_complex2complex

[gscfq--- via Gcc-bugs]

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

Bug ID: 107215
   Summary: ICE in gfc_real2real and gfc_complex2complex
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Additional examples affect versions down to at least r5 :


$ cat z1.f90
program p
  double precision, parameter :: z = 1.0d0
  real :: y(1)
  complex :: x(1)
  x = [real :: -'1'] * z
  y = z * [real :: -'1']
  x = [real :: -(.true.)] * z
  y = z * [real :: -(.true.)]
end


$ cat z2.f90
program p
  double precision, parameter :: z = 1.0d0
  real :: y(1)
  complex :: x(1)
  x = [complex :: -'1'] * z
  y = z * [complex :: -'1']
  x = [complex :: -(.true.)] * z
  y = z * [complex :: -(.true.)]
end


$ gfortran-13-20221009 -c z1.f90
f951: internal compiler error: Segmentation fault
0xd93caf crash_signal
../../gcc/toplev.cc:314
0x77ecb7 gfc_real2real(gfc_expr*, int)
../../gcc/fortran/arith.cc:2201
0x8526c2 gfc_convert_constant(gfc_expr*, bt, int)
../../gcc/fortran/simplify.cc:8762
#...


$ gfortran-13-20221009 -c z2.f90
f951: internal compiler error: Segmentation fault
0xd93caf crash_signal
../../gcc/toplev.cc:314
0x77f421 gfc_complex2complex(gfc_expr*, int)
../../gcc/fortran/arith.cc:2444
0x8526c2 gfc_convert_constant(gfc_expr*, bt, int)
../../gcc/fortran/simplify.cc:8762
0x7c9a3b do_simplify
../../gcc/fortran/intrinsic.cc:4658
0x7d5501 gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int, bool)
../../gcc/fortran/intrinsic.cc:5384
0x7b7958 gfc_type_convert_binary(gfc_expr*, int)
../../gcc/fortran/expr.cc:985
0x77c317 eval_intrinsic
../../gcc/fortran/arith.cc:1606
0x7eed8c match_add_operand
../../gcc/fortran/matchexp.cc:392
0x7eef3c match_level_2
../../gcc/fortran/matchexp.cc:480
0x7ef092 match_level_3
../../gcc/fortran/matchexp.cc:551
0x7ef184 match_level_4
../../gcc/fortran/matchexp.cc:599
0x7ef184 match_and_operand
../../gcc/fortran/matchexp.cc:693
0x7ef372 match_or_operand
../../gcc/fortran/matchexp.cc:722
0x7ef442 match_equiv_operand
../../gcc/fortran/matchexp.cc:765
0x7ef514 match_level_5
../../gcc/fortran/matchexp.cc:811
0x7ee8e1 gfc_match_expr(gfc_expr**)
../../gcc/fortran/matchexp.cc:870
0x7e5ec0 gfc_match(char const*, ...)
../../gcc/fortran/match.cc:1131
0x7e7c89 gfc_match_assignment()
../../gcc/fortran/match.cc:1330
0x812e40 match_word
../../gcc/fortran/parse.cc:67
0x812e40 decode_statement
../../gcc/fortran/parse.cc:363

[Bug fortran/107214] New: [13 Regression] ICE: base pointer cycle detected

[gscfq--- via Gcc-bugs]

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

Bug ID: 107214
   Summary: [13 Regression] ICE: base pointer cycle detected
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220911 and 20220918 :


$ cat z1.f90
program p
   integer, allocatable :: a
   !$omp target map(tofrom: a, a)
   !$omp end target
end


$ gfortran-13-20221009 -c z1.f90 -fopenmp
when processing group:
map(tofrom:*a) map(alloc:a [pointer assign, bias: 0])
z1.f90:3:33:

3 |!$omp target map(tofrom: a, a)
  | ^
internal compiler error: base pointer cycle detected
0xaee0b3 omp_tsort_mapping_groups_1
../../gcc/gimplify.cc:9571
0xaeded5 omp_tsort_mapping_groups_1
../../gcc/gimplify.cc:9614
0xb02820 omp_tsort_mapping_groups
../../gcc/gimplify.cc:9652
0xb02820 gimplify_scan_omp_clauses
../../gcc/gimplify.cc:10739
0xb08a0e gimplify_omp_workshare
../../gcc/gimplify.cc:15357
0xaf47ab gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16870
0xaf7ad8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7187
0xaf59cb gimplify_statement_list
../../gcc/gimplify.cc:2021
0xaf59cb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16773
0xaf7ad8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7187
0xaf8031 gimplify_bind_expr
../../gcc/gimplify.cc:1430
0xaf503b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16529
0xaf7ad8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7187
0xaf8b7b gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:17588
0xaf8fcd gimplify_function_tree(tree_node*)
../../gcc/gimplify.cc:17787
0x9808d7 cgraph_node::analyze()
../../gcc/cgraphunit.cc:676
0x983267 analyze_functions
../../gcc/cgraphunit.cc:1240
0x983c1d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2500

[Bug testsuite/107213] New test case c-c++-common/pointer-to-fn1.c uses unsupported option r13-3202-g67efffec943656

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug testsuite/107213] New: New test case c-c++-common/pointer-to-fn1.c uses unsupported option r13-3202-g67efffec943656

[seurer at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107213
   Summary: New test case c-c++-common/pointer-to-fn1.c uses
unsupported option  r13-3202-g67efffec943656
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:67efffec943656a509e036cd3c785a5c3d6885e1, r13-3202-g67efffec943656
make  -k check-gcc RUNTESTFLAGS="dg.exp=c-c++-common/pointer-to-fn1.c"
FAIL: c-c++-common/pointer-to-fn1.c  -Wc++-compat   (test for warnings, line
14)
FAIL: c-c++-common/pointer-to-fn1.c  -Wc++-compat   (test for warnings, line
15)
FAIL: c-c++-common/pointer-to-fn1.c  -Wc++-compat   (test for warnings, line
16)
FAIL: c-c++-common/pointer-to-fn1.c  -Wc++-compat   (test for warnings, line
17)
FAIL: c-c++-common/pointer-to-fn1.c  -Wc++-compat  (test for excess errors)
FAIL: c-c++-common/pointer-to-fn1.c(test for warnings, line 14)
FAIL: c-c++-common/pointer-to-fn1.c(test for warnings, line 15)
FAIL: c-c++-common/pointer-to-fn1.c(test for warnings, line 16)
FAIL: c-c++-common/pointer-to-fn1.c(test for warnings, line 17)
FAIL: c-c++-common/pointer-to-fn1.c   (test for excess errors)

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/pointer-to-fn1.c
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-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
-fcf-protection -std=c++11 -fpermissive -S -o pointer-to-fn1.s^M
cc1plus: error: '-fcf-protection=full' is not supported for this target^M
compiler exited with status 1
FAIL: c-c++-common/pointer-to-fn1.c(test for warnings, line 14)
FAIL: c-c++-common/pointer-to-fn1.c(test for warnings, line 15)
FAIL: c-c++-common/pointer-to-fn1.c(test for warnings, line 16)
FAIL: c-c++-common/pointer-to-fn1.c(test for warnings, line 17)


commit 67efffec943656a509e036cd3c785a5c3d6885e1 (HEAD, refs/bisect/bad)
Author: Marek Polacek 
Date:   Thu Sep 29 17:49:32 2022 -0400

c-family: ICE with [[gnu::nocf_check]] [PR106937]

[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Segher Boessenkool  ---
(In reply to H.J. Lu from comment #11)
> Assuming (reg:CCC 17 flags) is set to 1 by compare properly, how should

A MODE_CC RTL reg is never set to "1".  It is set to the result of a
comparison,
instead.  The semantics of a consumer of a MODE_CC depends on the producer.

> (insn 50 49 51 2 (parallel [
> (set (reg:SI 93)
> (neg:SI (ltu:SI (reg:CCC 17 flags)
> (const_int 0 [0]
> (clobber (reg:CC 17 flags))
> ]) "107172.c":4:10 1258 {*x86_movsicc_0_m1_neg}
>  (expr_list:REG_DEAD (reg:CCC 17 flags)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil
> 
> work?

The semantics of
  (ltu:SI (reg:CCC 17) (const_int 0))
is: the result of "ltu" of the producer of this reg 17, taken from 17 as mode
CCC (which means only the carry output is valid), and that result as a SImode
(which then depends on what STORE_FLAG_VALUE is for your target -- 1 or -1 for
most targets, but other values are more complicated).

It never means "1".  It never means "0".  Never.

To determine the semantics of this piece of RTL you need to see the setter(s)
of reg 17 feeding this use.  In this case, the setter was
  (set (reg:CCC 17)
   (ne:CCC (reg:SI 82)
   (const_int 0 [0])))
which has no meaning for a use that uses "ltu".

[Bug tree-optimization/107209] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-11
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> Looks like EVRP elimination fails to clean EH?  Or target folding.  Would be
> nice to have a testcase not requiring aarch64 intrinsics.

I tried but didn't crash.
```
#define vector __attribute__((vector_size(sizeof(double

vector double
foo1 (void)
{
  double v1 = 3.14159265359;
  double v2 = 1.383894;
  double vec_1_data[] = {v1};
  double vec_2_data[] = {v2};
  vector double vec_1 = {vec_1_data[0]};
  vector double vec_2 = {vec_2_data[0]};

  return vec_1*vec_2;
}
```

Before evrp on the working testcase:
```
  vec_1_data$0_3 = 3.1415926535906156975359772332012653350830078125e+0;
  vec_2_data$0_4 = 1.38389399574953335468308068811893463134765625e+0;
  _1 = vec_1_data$0_3;
  vec_1_9 = {_1};
  _2 = vec_2_data$0_4;
  vec_2_11 = {_2};
  [LP 1] _12 = vec_1_9 * vec_2_11;
```

But with the aarch64 intrinsics:
  vec_1_data$0_2 = 3.1415926535906156975359772332012653350830078125e+0;
  vec_2_data$0_3 = 1.38389399574953335468308068811893463134765625e+0;
  _10 = vec_1_data$0_2;
  _7 = {_10};
  _20 = vec_2_data$0_3;
  _21 = {_20};
  [LP 1] # .MEM_28 = VDEF <.MEM_4(D)>
  # USE = nonlocal escaped 
  # CLB = nonlocal escaped 
  _24 = __builtin_aarch64_fmulxdf (_10, _20);
```

aarch64_general_gimple_fold_builtin inside aarch64-builtins.cc which does the
folding and it looks correct.
`BUILTIN_GPF (BINOP, fmulx, 0, ALL)`

So it requires aarch64 intrinsics.
In GCC 12, the folding of fmulxdf or the multiply didn't happen during evrp
even.

[Bug libstdc++/88264] Support glibc-style tunables for

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> The emergency EH pool size should be tunable too.
> 
> From libsupc++/eh_alloc.cc:
> 
>   // Allocate the arena - we could add a GLIBCXX_EH_ARENA_SIZE
> environment
>   // to make this tunable.
>   arena_size = (EMERGENCY_OBJ_SIZE * EMERGENCY_OBJ_COUNT
>   + EMERGENCY_OBJ_COUNT * sizeof (__cxa_dependent_exception));
>   arena = (char *)malloc (arena_size);

Done for PR 68606.

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #22 from Jonathan Wakely  ---
Fixed for GCC 13

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #21 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:637e3668fdc17c4e226538fb14f9fab225433d01

commit r13-3234-g637e3668fdc17c4e226538fb14f9fab225433d01
Author: Jonathan Wakely 
Date:   Wed Oct 5 21:21:54 2022 +0100

libstdc++: Allow emergency EH alloc pool size to be tuned [PR68606]

Implement a long-standing request to support tuning the size of the
emergency buffer for allocating exceptions after malloc fails, or to
disable that buffer entirely.

It's now possible to disable the dynamic allocation of the buffer and
use a fixed-size static buffer, via --enable-libstdcxx-static-eh-pool.
This is a built-time choice that is baked into libstdc++ and so affects
all code linked against that build of libstdc++.

The size of the pool can be set by --with-libstdcxx-eh-pool-obj-count=N
which is measured in units of sizeof(void*) not bytes. A given exception
type such as std::system_error depends on the target, so giving a size
in bytes wouldn't be portable across 16/32/64-bit targets.

When libstdc++ is configured to use a dynamic buffer, the size of that
buffer can now be tuned at runtime by setting the GLIBCXX_TUNABLES
environment variable (c.f. PR libstdc++/88264). The number of exceptions
to reserve space for is controlled by the "glibcxx.eh_pool.obj_count"
and "glibcxx.eh_pool.obj_size" tunables. The pool will be sized to be
able to allocate obj_count exceptions of size obj_size*sizeof(void*) and
obj_count "dependent" exceptions rethrown by std::rethrow_exception.

With the ability to tune the buffer size, we can reduce the default pool
size on 32-bit and 16-bit targets. Most users never need to throw 1kB
exceptions in parallel from hundreds of threads after malloc is OOM. The
users who do need that can use the tunables to select larger sizes.

The old defaults can be chosen at runtime by setting GLIBCXX_TUNABLES
to:
64-bit: glibcxx.eh_pool.obj_count=64:glibcxx.eh_pool.obj_size=112
32-bit: glibcxx.eh_pool.obj_count=32:glibcxx.eh_pool.obj_size=104

Or approximated by configuring with:
64-bit: --with-libstdcxx-eh-pool-obj-count=252
32-bit: --with-libstdcxx-eh-pool-obj-count=94

libstdc++-v3/ChangeLog:

PR libstdc++/68606
* Makefile.in: Regenerate.
* acinclude.m4 (GLIBCXX_EMERGENCY_EH_ALLOC): New macro.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_EMERGENCY_EH_ALLOC.
* crossconfig.m4: Check for secure_getenv.
* doc/Makefile.in: Regenerate.
* doc/xml/manual/configure.xml: Document new configure options.
* doc/xml/manual/evolution.xml: Document addition of tunables.
* doc/xml/manual/using_exceptions.xml: Document emergency
buffer and tunables.
* doc/html/*: Regenerate.
* include/Makefile.in: Regenerate.
* libsupc++/Makefile.am: Use EH_POOL_FLAGS.
* libsupc++/Makefile.in: Regenerate.
* libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define in units
of sizeof(void*) not including the ABI's exception header.
(EMERGENCY_OBJ_COUNT): Define as target-independent calculation
based on word size.
(MAX_OBJ_COUNT): Define macro for upper limit on pool size.
(pool) [_GLIBCXX_EH_POOL_STATIC]: Use fixed-size buffer.
(pool::buffer_size_in_bytes): New static member function.
(pool::pool): Parse GLIBCXX_TUNABLES environment variable to set
pool size at runtime.
(pool::in_pool): Use std::less for total order.
(__freeres) [_GLIBCXX_EH_POOL_STATIC]: Do nothing.
(__cxa_free_exception, __cxa_free_dependent_exception): Add
[[unlikely]] attributes.
* po/Makefile.in: Regenerate.
* python/Makefile.in: Regenerate.
* src/Makefile.in: Regenerate.
* src/c++11/Makefile.in: Regenerate.
* src/c++17/Makefile.in: Regenerate.
* src/c++20/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.
* src/filesystem/Makefile.in: Regenerate.
* src/libbacktrace/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

[Bug libstdc++/88264] Support glibc-style tunables for

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:637e3668fdc17c4e226538fb14f9fab225433d01

commit r13-3234-g637e3668fdc17c4e226538fb14f9fab225433d01
Author: Jonathan Wakely 
Date:   Wed Oct 5 21:21:54 2022 +0100

libstdc++: Allow emergency EH alloc pool size to be tuned [PR68606]

Implement a long-standing request to support tuning the size of the
emergency buffer for allocating exceptions after malloc fails, or to
disable that buffer entirely.

It's now possible to disable the dynamic allocation of the buffer and
use a fixed-size static buffer, via --enable-libstdcxx-static-eh-pool.
This is a built-time choice that is baked into libstdc++ and so affects
all code linked against that build of libstdc++.

The size of the pool can be set by --with-libstdcxx-eh-pool-obj-count=N
which is measured in units of sizeof(void*) not bytes. A given exception
type such as std::system_error depends on the target, so giving a size
in bytes wouldn't be portable across 16/32/64-bit targets.

When libstdc++ is configured to use a dynamic buffer, the size of that
buffer can now be tuned at runtime by setting the GLIBCXX_TUNABLES
environment variable (c.f. PR libstdc++/88264). The number of exceptions
to reserve space for is controlled by the "glibcxx.eh_pool.obj_count"
and "glibcxx.eh_pool.obj_size" tunables. The pool will be sized to be
able to allocate obj_count exceptions of size obj_size*sizeof(void*) and
obj_count "dependent" exceptions rethrown by std::rethrow_exception.

With the ability to tune the buffer size, we can reduce the default pool
size on 32-bit and 16-bit targets. Most users never need to throw 1kB
exceptions in parallel from hundreds of threads after malloc is OOM. The
users who do need that can use the tunables to select larger sizes.

The old defaults can be chosen at runtime by setting GLIBCXX_TUNABLES
to:
64-bit: glibcxx.eh_pool.obj_count=64:glibcxx.eh_pool.obj_size=112
32-bit: glibcxx.eh_pool.obj_count=32:glibcxx.eh_pool.obj_size=104

Or approximated by configuring with:
64-bit: --with-libstdcxx-eh-pool-obj-count=252
32-bit: --with-libstdcxx-eh-pool-obj-count=94

libstdc++-v3/ChangeLog:

PR libstdc++/68606
* Makefile.in: Regenerate.
* acinclude.m4 (GLIBCXX_EMERGENCY_EH_ALLOC): New macro.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_EMERGENCY_EH_ALLOC.
* crossconfig.m4: Check for secure_getenv.
* doc/Makefile.in: Regenerate.
* doc/xml/manual/configure.xml: Document new configure options.
* doc/xml/manual/evolution.xml: Document addition of tunables.
* doc/xml/manual/using_exceptions.xml: Document emergency
buffer and tunables.
* doc/html/*: Regenerate.
* include/Makefile.in: Regenerate.
* libsupc++/Makefile.am: Use EH_POOL_FLAGS.
* libsupc++/Makefile.in: Regenerate.
* libsupc++/eh_alloc.cc (EMERGENCY_OBJ_SIZE): Define in units
of sizeof(void*) not including the ABI's exception header.
(EMERGENCY_OBJ_COUNT): Define as target-independent calculation
based on word size.
(MAX_OBJ_COUNT): Define macro for upper limit on pool size.
(pool) [_GLIBCXX_EH_POOL_STATIC]: Use fixed-size buffer.
(pool::buffer_size_in_bytes): New static member function.
(pool::pool): Parse GLIBCXX_TUNABLES environment variable to set
pool size at runtime.
(pool::in_pool): Use std::less for total order.
(__freeres) [_GLIBCXX_EH_POOL_STATIC]: Do nothing.
(__cxa_free_exception, __cxa_free_dependent_exception): Add
[[unlikely]] attributes.
* po/Makefile.in: Regenerate.
* python/Makefile.in: Regenerate.
* src/Makefile.in: Regenerate.
* src/c++11/Makefile.in: Regenerate.
* src/c++17/Makefile.in: Regenerate.
* src/c++20/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.
* src/filesystem/Makefile.in: Regenerate.
* src/libbacktrace/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

[Bug target/107185] [13 Regression] during RTL pass: vregs ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -ffast-math and lrintf()

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-3232-gb65945e7fb8d0f6cf911d371926d25e7ea82db62
Author: Jakub Jelinek 
Date:   Tue Oct 11 15:57:09 2022 +0200

i386: Fix up RTL checking ICE [PR107185]

On Tue, Oct 11, 2022 at 04:03:16PM +0800, liuhongt via Gcc-patches wrote:
> gcc/ChangeLog:
>
>   * config/i386/i386.md (*notxor_1): New post_reload
>   define_insn_and_split.
>   (*notxorqi_1): Ditto.

> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -10826,6 +10826,39 @@ (define_insn "*_1"
> (set_attr "type" "alu, alu, msklog")
> (set_attr "mode" "")])
>
> +(define_insn_and_split "*notxor_1"
> +  [(set (match_operand:SWI248 0 "nonimmediate_operand" "=rm,r,?k")
> + (not:SWI248
> +   (xor:SWI248
> + (match_operand:SWI248 1 "nonimmediate_operand" "%0,0,k")
> + (match_operand:SWI248 2 "" "r,,k"
> +   (clobber (reg:CC FLAGS_REG))]
> +  "ix86_binary_operator_ok (XOR, mode, operands)"
> +  "#"
> +  "&& reload_completed"
> +  [(parallel
> +[(set (match_dup 0)
> +   (xor:SWI248 (match_dup 1) (match_dup 2)))
> + (clobber (reg:CC FLAGS_REG))])
> +   (set (match_dup 0)
> + (not:SWI248 (match_dup 1)))]
> +{
> +  if (MASK_REGNO_P (REGNO (operands[0])))

This causes --enable-checking=yes,rtl,extra regression on
gcc.dg/store_merging_13.c test on x86_64-linux:
.../gcc/testsuite/gcc.dg/store_merging_13.c: In function 'f13':
.../gcc/testsuite/gcc.dg/store_merging_13.c:189:1: internal compiler error:
RTL check: expected code 'reg', have 'mem' in rhs_regno, at rtl.h:1932
0x7b0c8f rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
../../gcc/rtl.cc:916
0x8e74be rhs_regno
../../gcc/rtl.h:1932
0x9785fd rhs_regno
./genrtl.h:120
0x9785fd gen_split_260(rtx_insn*, rtx_def**)
../../gcc/config/i386/i386.md:10846
0x23596dc split_insns(rtx_def*, rtx_insn*)
../../gcc/config/i386/i386.md:16392
0xfccd5a try_split(rtx_def*, rtx_insn*, int)
../../gcc/emit-rtl.cc:3799
0x132e9d8 split_insn
../../gcc/recog.cc:3384
0x13359d5 split_all_insns()
../../gcc/recog.cc:3488
0x1335ae8 execute
../../gcc/recog.cc:4412
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Fixed thusly.

2022-10-11  Jakub Jelinek  

PR target/107185
* config/i386/i386.md (*notxor_1): Use MASK_REG_P (x) instead
of
MASK_REGNO_P (REGNO (x)).

[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE

[jan.zizka at nokia dot com via Gcc-bugs]

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

--- Comment #25 from Jan Žižka  ---
I have backported all three patches but true that I didn't try to test without
VN enhancement. Would it help if I'd try that with our production code and the
reproducers? Or anything else I could try so that you'd know if the VM
enhancement should be backported also?

[Bug lto/106540] [10/11 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6076

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:752d7664325037789ee4b634672e8e737ad9469c

commit r11-10307-g752d7664325037789ee4b634672e8e737ad9469c
Author: Richard Biener 
Date:   Mon Aug 8 09:07:23 2022 +0200

lto/106540 - fix LTO tree input wrt dwarf2out_register_external_die

I've revisited the earlier two workarounds for
dwarf2out_register_external_die
getting duplicate entries.  It turns out that r11-525-g03d90a20a1afcb
added dref_queue pruning to lto_input_tree but decl reading uses that
to stream in DECL_INITIAL even when in the middle of SCC streaming.
When that SCC then gets thrown away we can end up with debug nodes
registered which isn't supposed to happen.  The following adjusts
the DECL_INITIAL streaming to go the in-SCC way, using lto_input_tree_1,
since no SCCs are expected at this point, just refs.

PR lto/106540
PR lto/106334
* lto-streamer-in.c (lto_read_tree_1): Use lto_input_tree_1
to input DECL_INITIAL, avoiding to commit drefs.

(cherry picked from commit 4769ac6c5dfde2810a0266fe388211edc644e623)

[Bug tree-optimization/106513] [10/11 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10306-gec718fb7a3a58955017cd80f6a8927afbe340fc4
Author: Richard Biener 
Date:   Wed Aug 10 15:45:22 2022 +0200

tree-optimization/106513 - fix mistake in bswap symbolic number shifts

This fixes a mistake in typing a local variable in the symbolic
shift routine.

PR tree-optimization/106513
* gimple-ssa-store-merging.c (do_shift_rotate): Use uint64_t
for head_marker.

* gcc.dg/torture/pr106513.c: New testcase.

(cherry picked from commit f675afa4eeac9910a2c085a95aa04d6d9f2fd8d6)

[Bug middle-end/106027] [11 Regression] ICE: 'verify_gimple' failed (error: mismatching comparison operand types) since r11-2450-g10231958fcfb13bc

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.3.1
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug middle-end/106331] [10/11 Regression] Whole array assignment of empty string segfaults with -Og since r12-2633-ge5e164effa30fd2b

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:90d3b4dd84c08cc134578397d9c6b30b7dc4b440

commit r11-10305-g90d3b4dd84c08cc134578397d9c6b30b7dc4b440
Author: Richard Biener 
Date:   Tue Jul 19 09:57:22 2022 +0200

middle-end/106331 - fix mem attributes for string op arguments

get_memory_rtx tries hard to come up with a MEM_EXPR to record
in the memory attributes but in the last fallback fails to properly
account for an unknown offset and thus, as visible in this testcase,
incorrect alignment computed from set_mem_attributes.  The following
rectifies both parts.

PR middle-end/106331
* builtins.c (get_memory_rtx): Compute alignment from
the original address and set MEM_OFFSET to unknown when
we create a MEM_EXPR from the base object of the address.

* gfortran.dg/pr106331.f90: New testcase.

(cherry picked from commit e4ff11a8f2e80adb8ada69bf35ee6a1ab18a9c85)

[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:752d7664325037789ee4b634672e8e737ad9469c

commit r11-10307-g752d7664325037789ee4b634672e8e737ad9469c
Author: Richard Biener 
Date:   Mon Aug 8 09:07:23 2022 +0200

lto/106540 - fix LTO tree input wrt dwarf2out_register_external_die

I've revisited the earlier two workarounds for
dwarf2out_register_external_die
getting duplicate entries.  It turns out that r11-525-g03d90a20a1afcb
added dref_queue pruning to lto_input_tree but decl reading uses that
to stream in DECL_INITIAL even when in the middle of SCC streaming.
When that SCC then gets thrown away we can end up with debug nodes
registered which isn't supposed to happen.  The following adjusts
the DECL_INITIAL streaming to go the in-SCC way, using lto_input_tree_1,
since no SCCs are expected at this point, just refs.

PR lto/106540
PR lto/106334
* lto-streamer-in.c (lto_read_tree_1): Use lto_input_tree_1
to input DECL_INITIAL, avoiding to commit drefs.

(cherry picked from commit 4769ac6c5dfde2810a0266fe388211edc644e623)

[Bug tree-optimization/106131] [10/11 Regression] -fstrict-aliasing breaks normal program that does not use any pointer or reference

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10304-gbefa9c8b072ef8b81d4a5b46d83f81cd58318c2b
Author: Richard Biener 
Date:   Thu Jun 30 10:33:40 2022 +0200

tree-optimization/106131 - wrong code with FRE rewriting

The following makes sure to not use the original TBAA type for
looking up a value across an aggregate copy when we had to offset
the read.

2022-06-30  Richard Biener  

PR tree-optimization/106131
* tree-ssa-sccvn.c (vn_reference_lookup_3): Force alias-set
zero when offsetting the read looking through an aggregate
copy.

* g++.dg/torture/pr106131.C: New testcase.

(cherry picked from commit 9701432ff79926a5dd3303be3417e0bd0c24140b)

[Bug tree-optimization/106112] [10/11 Regression] wrong code at -Os and above on x86_64-linux-gnu since r10-2711-g3ed01d5408045d80

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10303-gb7878f05553bcf569a987dff8a7ef8b045b8d26c
Author: Richard Biener 
Date:   Tue Jun 28 13:57:29 2022 +0200

tree-optimization/106112 - fix CSE from wider operation

The following fixes a mistake in looking up an extended operand
in the CSE of a truncated operation.

2022-06-28  Richard Biener  

PR tree-optimization/106112
* tree-ssa-sccvn.c (valueized_wider_op): Properly extend
a constant operand according to its type.

* gcc.dg/torture/pr106112.c: New testcase.

(cherry picked from commit 2dbb45d6dc0d20dc159b3d8e27ebb6825074827a)

[Bug middle-end/106027] [11 Regression] ICE: 'verify_gimple' failed (error: mismatching comparison operand types) since r11-2450-g10231958fcfb13bc

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10302-ga27e5fc76a49b759d271a828f225899434b537e9
Author: Richard Biener 
Date:   Mon Jun 20 13:40:50 2022 +0200

middle-end/106027 - fix types in needle folding

The fold_to_nonsharp_ineq_using_bound folding ends up creating invalid
typed IL which confuses later foldings.  The following fixes that.

2022-06-20  Richard Biener  

PR middle-end/106027
* fold-const.c (fold_to_nonsharp_ineq_using_bound): Use the
type of the prevailing comparison for the new comparison type.
(fold_binary_loc): Use proper types for the A < X && A + 1 > Y
to A < X && A >= Y folding.

* gcc.dg/pr106027.c: New testcase.

(cherry picked from commit 713f2fd923442b1be620a44240ddf786ae0ab476)

[Bug tree-optimization/107096] Fully masking vectorization with AVX512 ICEs gcc.dg/vect/vect-over-widen-*.c

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Richard Biener  ---
(In reply to rsand...@gcc.gnu.org from comment #8)
> (In reply to rguent...@suse.de from comment #7)
> > more like precision but x86 uses QImode for two-element, four-element
> > and eight-element masks (rather than two partial integer modes with
> > two and four bits precision).
> Ah, OK.  So yeah, maybe the precision of the vector boolean element *
> the number of elements.

For SVE the following holds:

diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 1996ecfee7a..9b24b481867 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -10097,6 +10097,12 @@ vect_get_loop_mask (gimple_stmt_iterator *gsi,
vec_loop_masks *masks,
  TYPE_VECTOR_SUBPARTS (vectype)));
   gimple_seq seq = NULL;
   mask_type = truth_type_for (vectype);
+  /* Assert that both mask types have the same total number of value
+bits.  */
+  gcc_assert (known_eq (TYPE_PRECISION (TREE_TYPE (TREE_TYPE (mask)))
+   * TYPE_VECTOR_SUBPARTS (TREE_TYPE (mask)),
+   TYPE_PRECISION (TREE_TYPE (mask_type))
+   * TYPE_VECTOR_SUBPARTS (mask_type)));
   mask = gimple_build (, VIEW_CONVERT_EXPR, mask_type, mask);
   if (seq)
gsi_insert_seq_before (gsi, seq, GSI_SAME_STMT);

for AVX the TYPE_PRECISION is always 1 so for unequal subparts we cannot
directly share masks.

I'm going to change LOOP_VINFO_MASKS from an array indexed by nV to
a two-dimensional indexed by nV and bit-precision * subparts.  Well,
probably using a hash_map instead since this will be quite sparse.
Or maybe not, but at least dynamically growing as we do now is difficult
and subparts can be non-constant.

[Bug tree-optimization/106901] [13 Regression] False positive -Warray-bounds with -O2 or higher?

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Carlos Galvez  ---
I understand the reasoning, but the loop _can_ executed in other cases where
the function is called with different arguments:

bar(vec, 5, 5);  // Warray-bounds, loop not executed, no runtime OOB.
bar(vec, 5, 4);  // No Warray-bounds, loop executed,  no runtime OOB.

There is no OOB access in either case, so the compiler is incorrect in claiming
there is one. If there were, the OOB access would show up in Valgrind or ASan,
which is not the case.

Please note that the presence of False Positives in basic compiler warnings
like Wall or Wextra damages the credibility of compiler warnings. Warnings that
may have FPs should go in a different category, or as part of a separate tool,
like a static analyzer.

[Bug tree-optimization/105937] [12 Regression] maybe-uninitialized with std::optional

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||12.2.0
 Resolution|--- |FIXED
  Known to work||12.2.1

--- Comment #10 from Richard Biener  ---
Fixed.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Bug 105937 Summary: [12 Regression] maybe-uninitialized with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105937

   What|Removed |Added

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

[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #24 from Richard Biener  ---
Note I'm still pondering whether to backport the VN enhancement, for now I've
backported the VN/PRE optimization regression fix.

[Bug tree-optimization/106934] [10/11/12 Regression] ICE: verify_gimple failed since r9-5682-gef310a95a934d0f3

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8821-gc3119f575a04845fbbebbf90b5cdea88d5d76156
Author: Richard Biener 
Date:   Wed Sep 14 09:00:35 2022 +0200

tree-optimization/106934 - avoid BIT_FIELD_REF of bitfields

The following avoids creating BIT_FIELD_REF of bitfields in
update-address-taken.  The patch doesn't implement punning to
a full precision integer type but leaves a comment according to
that.

PR tree-optimization/106934
* tree-ssa.cc (non_rewritable_mem_ref_base): Avoid BIT_FIELD_REFs
of bitfields.
(maybe_rewrite_mem_ref_base): Likewise.

* gfortran.dg/pr106934.f90: New testcase.

(cherry picked from commit 05f5c42cb42c5088187d44cc45a5f671d19ad8c5)

[Bug tree-optimization/106922] [12 Regression] Bogus uninitialized warning on boost::optional<>>, missed FRE

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-8820-ge364e27b6636ba09755790358910f199d07194b3
Author: Richard Biener 
Date:   Thu Sep 15 13:33:23 2022 +0200

tree-optimization/106922 - PRE and virtual operand translation

PRE implicitely keeps virtual operands at the blocks incoming version
but the explicit updating point during PHI translation fails to trigger
when there are no PHIs at all in a block.  Later lazy updating then
fails because of a too lose block check.  A similar issues plagues
reference invalidation when checking the ANTIC_OUT to ANTIC_IN
translation.  The following fixes both and makes the lazy updating
work.

The diagnostic testcase unfortunately requires boost so the
testcase is the one I reduced for a missed optimization in PRE.
The testcase fails with -m32 on x86_64 because we optimize too
much before PRE which causes PRE to not trigger so we fail to
eliminate a full redundancy.  I'm going to open a separate bug
for this.  Hopefully the !lp64 selector is good enough.

PR tree-optimization/106922
* tree-ssa-pre.cc (translate_vuse_through_block): Only
keep the VUSE if its def dominates PHIBLOCK.
(prune_clobbered_mems): Rewrite logic so we check whether
a value dies in a block when the VUSE def doesn't dominate it.

* g++.dg/tree-ssa/pr106922.C: New testcase.

(cherry picked from commit 5edf02ed2b6de024f83a023d046a6a18f645bc83)

[Bug middle-end/106892] [11/12 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:2b9e1f7ff476059724cca4b11d39972655d4468f

commit r12-8819-g2b9e1f7ff476059724cca4b11d39972655d4468f
Author: Richard Biener 
Date:   Fri Sep 9 12:06:38 2022 +0200

tree-optimization/106892 - avoid invalid pointer association in predcom

When predictive commoning builds a reference for iteration N it
prematurely associates a constant offset into the MEM_REF offset
operand which can be invalid if the base pointer then points
outside of an object which alias-analysis does not consider valid.

PR tree-optimization/106892
* tree-predcom.cc (ref_at_iteration): Do not associate the
constant part of the offset into the MEM_REF offset
operand, across a non-zero offset.

* gcc.dg/torture/pr106892.c: New testcase.

(cherry picked from commit a8b0b13da7379feb31950a9d2ad74b98a29c547f)

[Bug tree-optimization/105937] [12 Regression] maybe-uninitialized with std::optional

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:627132c9bf9439bf0ac83bb092182055c1e0f3ab

commit r12-8818-g627132c9bf9439bf0ac83bb092182055c1e0f3ab
Author: Richard Biener 
Date:   Fri Aug 19 14:12:52 2022 +0200

tree-optimization/105937 - avoid uninit diagnostics crossing iterations

The following avoids adding PHIs to the worklist for uninit processing
if we reach them following backedges.  That confuses predicate analysis
because it assumes the use is happening in the same iteration as the the
definition.  For the testcase in the PR the situation is like

void foo (int val)
{
  int uninit;
  # val = PHI <..> (B)
  for (..)
{
  if (..)
{
  .. = val; (C)
  val = uninit;
}
  # val = PHI <..> (A)
}
}

and starting from (A) with 'uninit' as argument we arrive at (B)
and from there at (C).  Predicate analysis then tries to prove
the predicate of (B) (not the backedge) can prove that the
path from (B) to (C) is unreachable which isn't really what it
necessary - that's what we'd need to do when the preheader
edge of the loop were the edge with the uninitialized def.

So the following makes those cases intentionally false negatives.

PR tree-optimization/105937
* tree-ssa-uninit.cc (find_uninit_use): Do not queue PHIs
on backedges.
(execute_late_warn_uninitialized): Mark backedges.

* g++.dg/uninit-pr105937.C: New testcase.

(cherry picked from commit c77fae1ca796d6ea06d5cd437909905c3d3d771c)

[Bug tree-optimization/107212] [11/12 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||13.0
Summary|[11/12/13 Regression] Wrong |[11/12 Regression] Wrong
   |vectorizer code since   |vectorizer code since
   |r11-718-gc735929a2503a7d0   |r11-718-gc735929a2503a7d0

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar, many thanks for the report and the nice testcase.

[Bug tree-optimization/107212] [11/12/13 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r13-3226-gee467644c53ee2f7d633a8e1f53603feafab4351
Author: Richard Biener 
Date:   Tue Oct 11 11:34:55 2022 +0200

tree-optimization/107212 - SLP reduction of reduction paths

The following fixes an issue with how we handle epilogue generation
for SLP reductions of reduction paths where the actual live lanes
are not "canonical".  We need to make sure to identify all live
lanes as reductions and thus have to iterate over all participating
SLP lanes when walking the reduction SSA use-def chain.  Also the
previous attempt likely to mitigate such issue in
vectorizable_live_operation is misguided and has to be removed.

PR tree-optimization/107212
* tree-vect-loop.cc (vectorizable_reduction): Make sure to
set STMT_VINFO_REDUC_DEF for all live lanes in a SLP
reduction.
(vectorizable_live_operation): Do not pun to the SLP
node representative for reduction epilogue generation.

* gcc.dg/vect/pr107212-1.c: New testcase.
* gcc.dg/vect/pr107212-2.c: Likewise.

[Bug target/107093] AVX512 mask operations not simplified in fully masked loop

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #9 from rguenther at suse dot de  ---
On Tue, 11 Oct 2022, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107093
> 
> --- Comment #8 from Hongtao.liu  ---
> 
> > 
> > One downside for a fully masked body is that we're using masked stores
> > which usually have higher latency due to the "merge" semantics which
> > means an extra memory input + merge operation.  Not sure if modern
> > uArchs can optimize the all-ones mask case, the vectorizer, for
> Also I guess mask store won't be store forward even load is inside the mask
> store.

I guess the masking of the store is resolved in the load-store unit
and not by splitting the operation into a load, modify, store because
that cannot easily hide exceptions.  So yes, a masked store in the
store buffer likely cannot act as forwarding source (though the
actual mask should be fully resolved there) since the actual
merging will take place later.

[Bug target/107093] AVX512 mask operations not simplified in fully masked loop

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---

> 
> One downside for a fully masked body is that we're using masked stores
> which usually have higher latency due to the "merge" semantics which
> means an extra memory input + merge operation.  Not sure if modern
> uArchs can optimize the all-ones mask case, the vectorizer, for
Also I guess mask store won't be store forward even load is inside the mask
store.

[Bug target/107093] AVX512 mask operations not simplified in fully masked loop

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Richard Biener  ---
(In reply to Hongtao.liu from comment #5)
> Also i think masked epilog(--param=vect-partial-vector-usage=1) should be
> good for general cases under AVX512, espicially when main loop's vector
> width is 512, and the remain tripcount is not enough for 256-bit
> vectorization but ok for 128-bit vectorization.

Yes, for the fully masked variant I was mostly targeting -O2 with its
very-cheap (size wise) cost model.  Since we don't vectorize the
epilogue of a vectorized epilogue (yet) going fully masked there
should indeed help.  Also when we start to use the unroll hint the
vectorized epilogue might get full width iterations to handle as well.

One downside for a fully masked body is that we're using masked stores
which usually have higher latency due to the "merge" semantics which
means an extra memory input + merge operation.  Not sure if modern
uArchs can optimize the all-ones mask case, the vectorizer, for
.MASK_STORE, still has the code to change those to emit a mask
compare against all-zeros and only conditionally doing a .MASK_STORE.
That could be enhanced to single out the all-ones case, at least for
the .MASK_STOREs in a main fully masked loop when the mask is only
from the iteration (rather than conditional execution).

[Bug target/107093] AVX512 mask operations not simplified in fully masked loop

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Richard Biener  ---
(In reply to Hongtao.liu from comment #4)
> change "*k, CBC" to "?k, CBC", in *mov{qi,hi,si,di}_internal.
> then RA works good to choose kxnor for setting constm1_rtx to mask register,
> and i got below with your attached patch(change #if 0 to #if 1), seems
> better than orginal patch.
> 
>  6foo:
>  7.LFB0:
>  8.cfi_startproc
>  9testl   %edi, %edi
> 10jle .L9
> 11kxnorb  %k1, %k1, %k1
> 12cmpl$4, %edi
> 13jl  .L11
> 14.L3:
> 15vbroadcastsd.LC2(%rip), %ymm3
> 16vmovdqa .LC0(%rip), %xmm2
> 17xorl%eax, %eax
> 18xorl%ecx, %ecx
> 19.p2align 4,,10
> 20.p2align 3
> 21.L7:
> 22vmovapd b(%rax), %ymm0{%k1}
> 23addl$4, %ecx
> 24movl%edi, %edx
> 25vmulpd  %ymm3, %ymm0, %ymm1
> 26subl%ecx, %edx
> 27cmpl$4, %edx
> 28vmovapd %ymm1, a(%rax){%k1}
> 29vpbroadcastd%edx, %xmm1
> 30movl$-1, %edx
> 31vpcmpd  $1, %xmm1, %xmm2, %k1
> 32kmovb   %k1, %esi
> 33cmovge  %edx, %esi

not sure if the round-trip to GPRs for the sake
of a cmovge is worth, I guess a branch would be
better.

[Bug tree-optimization/107206] Bogus -Wuninitialized in std::optional

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
Btw, in other places I saw it's very much wanted to scalarize std::optional
because that's often the best way to figure whether it's engaged or not and
optimize dead code based on that.  So not scalarizing probably isn't the best
answer, still it would be nice to understand why SRA picks 'int' here even
though there's no access of that.

[Bug libstdc++/107206] Bogus -Wuninitialized in std::optional

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
So this goes wrong in SRA somewhere where we decide to scalarize yD.11526
with its std::optional member which isn't engaged.  Before early SRA we have

  MEM[(struct YD.10174 *)] ={v} {CLOBBER};
  MEM[(struct YD.10174 *)].xD.10179.iD.10156 = 0;
  MEM[(struct optionalD.10180 *) + 4B] ={v} {CLOBBER};
  MEM[(union _StorageD.10576 *) + 4B] ={v} {CLOBBER};
  MEM[(struct _Optional_payload_baseD.10507 *) + 4B]._M_engagedD.10644
= 0;
  D.11546 ={v} {CLOBBER};
  MEM[(struct XD.10147 *)] ={v} {CLOBBER};
  _22 = MEM[(const struct XD.10147 &)].iD.10156;
  MEM[(struct XD.10147 *)].iD.10156 = _22;
  D.11546.oD.11384 = yD.11526.oD.11384;
  MEM[(struct YD.10174 *)] ={v} {CLOBBER};
  MEM[(struct XD.10147 *)] ={v} {CLOBBER};
  _21 = MEM[(const struct XD.10147 &)].iD.10156;
  MEM[(struct XD.10147 *)].iD.10156 = _21;
  MEM[(struct YD.10174 *)].oD.11384 = MEM[(const struct YD.10174
&)].oD.11384;
  D.11546 ={v} {CLOBBER(eol)};
  MEM[(struct _Optional_baseD.10197 *)] ={v} {CLOBBER};
  MEM[(struct __as_base D.10805 &)] ={v} {CLOBBER};
  MEM[(union _StorageD.10576 *)] ={v} {CLOBBER};
  MEM[(union _StorageD.10576 *)]._M_valueD.10616 = 1;
  MEM[(struct _Optional_payload_baseD.10507 *)]._M_engagedD.10644 = 1;
  zD.11527.yD.11476.oD.11384 = D.11678;
  D.11678 ={v} {CLOBBER(eol)};
  MEM[(struct YD.10174 *)] ={v} {CLOBBER};
  MEM[(struct XD.10147 *)] ={v} {CLOBBER};
  _19 = MEM[(const struct XD.10147 &)].iD.10156;
  MEM[(struct XD.10147 *)].iD.10156 = _19;
  MEM[(struct YD.10174 *)].oD.11384 = MEM[(const struct YD.10174
&)].oD.11384;
  fD.11523 ();

and SRA possibly follows the copy chains eventually seeing the
value accesses to D.11678 and deciding based on that the type to use
to access the value union of std::optional which is (simplified)

  struct _Empty_byte { };
  union _Storage {
  _Empty_byte _M_empty;
  _Up _M_value;
  }

with _Up being int in this testcase.  Note that _M_empty is properly
initialized but as the store is to an empty type this store is elided
by gimplification.

Note that SRA doesn't dump anything on yD.11526 but still generates

  D.11546.oD.11384 = yD.11526.oD.11384;
  SR.19_9 = MEM  [(struct optionalD.10180 *) + 4B];
  SR.20_6 = MEM  [(struct optionalD.10180 *) + 8B];

possibly from the scalarization of D.11546:

Created a replacement for D.11546 offset: 0, size: 32: SR.18D.11910
Created a replacement for D.11546 offset: 32, size: 32: SR.19D.11911
Changing the type of a replacement for D.11546 offset: 64, size: 8  to an
integer.
Created a replacement for D.11546 offset: 64, size: 8: SR.20D.11912
...
access { base = (11546)'D.11546', offset = 32, size = 64, expr = D.11546.o,
type = struct optional, reverse = 0, grp_read = 1, grp_write = 1,
grp_assignment_read = 1, grp_assignment_write = 1, grp_scalar_read = 0,
grp_scalar_write = 0, grp_total_scalarization = 0, grp_hint = 0, grp_covered =
0, grp_unscalarizable_region = 0, grp_unscalarized_data = 1,
grp_same_access_path = 1, grp_partial_lhs = 0, grp_to_be_replaced = 0,
grp_to_be_debug_replaced = 0}

here D.11546.o is of an aggregate type containing a union member.  Somehow
there's

* access { base = (11546)'D.11546', offset = 32, size = 32, expr =
D.11546.o.D.11379._M_payload.D.10892._M_payload._M_value, type = int, reverse =
0, grp_read = 1, grp_write = 1, grp_assignment_read = 1, grp_assignment_write =
1, grp_scalar_read = 0, grp_scalar_write = 0, grp_total_scalarization = 0,
grp_hint = 0, grp_covered = 1, grp_unscalarizable_region = 0,
grp_unscalarized_data = 0, grp_same_access_path = 0, grp_partial_lhs = 0,
grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0}

but I don't see any such access in the IL before SRA?!

[Bug c++/107211] [10/11/12/13 Regression] GCC compiles invalid use of non static member function in noexcept operator

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-10-11
   Priority|P3  |P2
  Known to work||8.5.0
Summary|GCC compiles invalid use of |[10/11/12/13 Regression]
   |non static member function  |GCC compiles invalid use of
   |in noexcept operator|non static member function
   ||in noexcept operator
  Known to fail||10.4.1, 11.3.1, 12.2.1,
   ||13.0, 9.5.0
   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
Started with r9-4187-g205d542ad55d8d

re PR c++/52869 ([DR 1207] "this" not being allowed in noexcept clauses)

[Bug target/107093] AVX512 mask operations not simplified in fully masked loop

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
Also i think masked epilog(--param=vect-partial-vector-usage=1) should be good
for general cases under AVX512, espicially when main loop's vector width is
512, and the remain tripcount is not enough for 256-bit vectorization but ok
for 128-bit vectorization.

[Bug libstdc++/107206] Bogus -Wuninitialized in std::optional

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
The aggregate copy is intended, because std::optional must have a trivial
copy constructor if T has a trivial copy constructor.

There should be no uninitialized value, because the std::optional's storage
member has a  default constructor that inits the first member of the union (an
empty struct):

  struct _Empty_byte { };

  template>
union _Storage
{
  constexpr _Storage() noexcept : _M_empty() { }

  // ...

  _Empty_byte _M_empty;
  _Up _M_value;
};

The compiler seems to be eliding the _M_empty() initialization, because
_M_empty has no value bits, it's all padding.

[Bug target/107093] AVX512 mask operations not simplified in fully masked loop

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
change "*k, CBC" to "?k, CBC", in *mov{qi,hi,si,di}_internal.
then RA works good to choose kxnor for setting constm1_rtx to mask register,
and i got below with your attached patch(change #if 0 to #if 1), seems better
than orginal patch.

 6foo:
 7.LFB0:
 8.cfi_startproc
 9testl   %edi, %edi
10jle .L9
11kxnorb  %k1, %k1, %k1
12cmpl$4, %edi
13jl  .L11
14.L3:
15vbroadcastsd.LC2(%rip), %ymm3
16vmovdqa .LC0(%rip), %xmm2
17xorl%eax, %eax
18xorl%ecx, %ecx
19.p2align 4,,10
20.p2align 3
21.L7:
22vmovapd b(%rax), %ymm0{%k1}
23addl$4, %ecx
24movl%edi, %edx
25vmulpd  %ymm3, %ymm0, %ymm1
26subl%ecx, %edx
27cmpl$4, %edx
28vmovapd %ymm1, a(%rax){%k1}
29vpbroadcastd%edx, %xmm1
30movl$-1, %edx
31vpcmpd  $1, %xmm1, %xmm2, %k1
32kmovb   %k1, %esi
33cmovge  %edx, %esi
34addq$32, %rax
35kmovb   %esi, %k1
36kortestb%k1, %k1
37jne .L7
38vzeroupper
39.L9:
40ret
41.p2align 4,,10
42.p2align 3
43.L11:
44vmovdqa .LC0(%rip), %xmm2
45vpbroadcastd%edi, %xmm1
46vpcmpd  $1, %xmm1, %xmm2, %k1
47jmp .L3
48.cfi_endproc

[Bug tree-optimization/107212] [11/12/13 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Richard Biener  ---
Yes, the issue is latent for longer I think.

[Bug tree-optimization/107212] [11/12/13 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
So the speciality here is that with the SLP reduction we have the live lanes
split across the sum and the convert.  That wrecks havoc with
vectorizable_reduction following one of the lanes in the loop assigning
STMT_VINFO_REDUC_DEF to the reduction chain.  We simply do

  /* ???  For epilogue generation live members of the chain need
 to point back to the PHI via their original stmt for
 info_for_reduction to work.  */
  if (STMT_VINFO_LIVE_P (vdef))
STMT_VINFO_REDUC_DEF (def) = phi_info;

but in this case this misses one of the paths.  Also we're not reliably
following the representative here.  Plus vectorizable_live_operation
doesn't get the representative but the actual scalar stmt defining the
live lane (on purpose).  So the fix is to make sure the above setting
of STMT_VINFO_REDUC_DEF covers all live lanes of the SLP node.  For
vectorizable_live_operation the

  else
/* For SLP reductions the meta-info is attached to
   the representative.  */
stmt_info = SLP_TREE_REPRESENTATIVE (slp_node);

doing is then wrong and

  /* For SLP reductions we vectorize the epilogue for
 all involved stmts together.  */
  else if (slp_index != 0)
return true;

is also suspicious then but it seems we cope with the conversions just
fine.  So we're actually vectorizing the epilogue for the live lane 0
in the reduction chain but analysis might end up not following the lane 0
SSA use-def chain and identifying lane > 0 reductions is just to avoid
non-reduction live code gen.

[Bug target/107093] AVX512 mask operations not simplified in fully masked loop

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:498ad738690b3c464f901d63dcd4d0f49a50dd00

commit r13-3218-g498ad738690b3c464f901d63dcd4d0f49a50dd00
Author: liuhongt 
Date:   Mon Oct 10 11:31:48 2022 +0800

Add define_insn_and_split to support general version of "kxnor".

For genereal_reg_operand, it will be splitted into xor + not.
For mask_reg_operand, it will be splitted with UNSPEC_MASK_OP just
like what we did for other logic operations.

The patch will optimize xor+not to kxnor when possible.

gcc/ChangeLog:

PR target/107093
* config/i386/i386.md (*notxor_1): New post_reload
define_insn_and_split.
(*notxorqi_1): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr107093.c: New test.

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #8 from Aldy Hernandez  ---
fixed

[Bug c/92286] Possible improvement for -Wduplicated-cond warning

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Liška  ---
> trunk.git/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:547:
> 27: style: Expression is always true because 'else if' condition is opposite
> to previous condition at line 538. [multiCondition]

This one is correct, but the code assumes there's no fallback edge:

...
} else if (chunk_size > page_size) {
  // One chunk covers multiple pages, Some chunks are crossing page
  // boundaries. Some pages contain one chunk, some contain two.
  full_pages_chunk_count_max = 2;
  same_chunk_count_per_page = false;
} else {
  UNREACHABLE("All chunk_size/page_size ratios must be handled.");
}

Thus I'm going to leave it.

[Bug tree-optimization/107212] [11/12/13 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Liška  ---
Hmm, have a test-case that is miscompiled since r10-4200-gb7ff7cef5005721e:

$ cat pr107212.c
int sum_1 = 0;

int main() {
  unsigned int tab[6][2] = {{150, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}};

  int sum_0 = 0;

  for (int t = 0; t < 6; t++) {
sum_0 += tab[t][0];
sum_1 += tab[t][0];
  }

  if (sum_0 < 100 || sum_0 > 200)
__builtin_abort();
  return 0;
}

$ gcc pr107212.c -O3 -std=c99 && ./a.out
Aborted (core dumped)

[Bug tree-optimization/107212] [11/12/13 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/107212] [11/12/13 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Richard Biener  ---
Confirmed.  We vectorize the loop and that triggers full constant folding
leading to the wrong result somehow.

Same issue with GCC 11 when you add -ftree-vectorize or use -O3, not observed
with GCC 10.

The reduction epilogue of the SLP reduction looks duplicate wrong.

[Bug tree-optimization/107212] [11/12/13 Regression] Wrong vectorizer code since r11-718-gc735929a2503a7d0

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|-O2 and -O3 optimizer bug   |[11/12/13 Regression] Wrong
   ||vectorizer code since
   ||r11-718-gc735929a2503a7d0
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
   Target Milestone|--- |11.5
   Keywords||wrong-code
   Last reconfirmed||2022-10-11

--- Comment #1 from Martin Liška  ---
A bit reduced test-case:

$ cat pr107212.c
int main() {
unsigned int tab[6][2] = { {69, 73}, {36, 40}, {24, 16}, {16, 11}, {4, 5},
{3, 1} };

int flag = 1;
int sum_0 = 0;
int sum_1 = 0;

for(int t=0; t<6; t++) {
sum_0 += tab[t][0];
sum_1 += tab[t][1];
}

int x1 = (sum_0 < 100);
int x2 = (sum_0 > 200);
int x3 = (x1 || x2);

if(sum_1 > 200) {
flag=0;
}

__builtin_printf("sum_1: %d\n", sum_1);
if (x1 || x2)
  __builtin_abort ();

return 0;
}

With -O3 it started with r11-718-gc735929a2503a7d0.

[Bug tree-optimization/107195] [13 Regression] wrong code with "-O1 -fno-tree-ccp" on x86_64-linux-gnu since r13-3090-gdf4c584c567263fd

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r13-3217-gc4d15dddf6b9eacb36f535807ad2ee364af46e04
Author: Aldy Hernandez 
Date:   Mon Oct 10 20:42:10 2022 +0200

[PR107195] Set range to zero when nonzero mask is 0.

When solving 0 = _15 & 1, we calculate _15 as:

[irange] int [-INF, -2][0, +INF] NONZERO 0xfffe

The known value of _15 is [0, 1] NONZERO 0x1 which is intersected with
the above, yielding:

[0, 1] NONZERO 0x0

This eventually gets copied to a _Bool [0, 1] NONZERO 0x0.

This is problematic because here we have a bool which is zero, but
returns false for irange::zero_p, since the latter does not look at
nonzero bits.  This causes logical_combine to assume the range is
not-zero, and all hell breaks loose.

I think we should just normalize a nonzero mask of 0 to [0, 0] at
creation, thus avoiding all this.

PR tree-optimization/107195

gcc/ChangeLog:

* value-range.cc (irange::set_range_from_nonzero_bits): Set range
to [0,0] when nonzero mask is 0.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr107195-1.c: New test.
* gcc.dg/tree-ssa/pr107195-2.c: New test.

[Bug libstdc++/107206] Bogus -Wuninitialized in std::optional

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c++ |libstdc++
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We diagnose

 [local count: 1073741824]:
MEM[(struct optional *) + 4B] ={v} {CLOBBER};
MEM[(union _Storage *) + 4B] ={v} {CLOBBER};
MEM[(struct _Optional_payload_base *) + 4B]._M_engaged = 0;
D.11546.o = y.o;
SR.27_14 = MEM  [(struct optional *) + 4B];<- this
MEM  [(struct optional *) + 4B] = SR.27_14;
MEM  [(struct optional *) + 8B] = 0;
MEM[(struct Y *)].o = MEM[(const struct Y &)].o;
D.11546 ={v} {CLOBBER(eol)};
MEM[(struct Y *)] ={v} {CLOBBER};
MEM[(struct X *)] ={v} {CLOBBER};
MEM[(struct X *)].i = 0;
MEM  [(struct optional *) + 4B] = 1;
MEM  [(struct optional *) + 8B] = 1;
MEM[(struct Y *)].o = MEM[(const struct Y &)].o;
f ();
y ={v} {CLOBBER(eol)};
z ={v} {CLOBBER(eol)};
w ={v} {CLOBBER(eol)};
return;

Here the aggregate copy

   D.11546.o = y.o;

is effectively scalarized and that accesses the data member of the not
engaged std::optional<>.

IMHO that's a standard library issue?  The copy is due to the by value
passing and we get in .original

  <>>
  (const struct Y &)  ) >;

which eventually leads to

  Y::Y (, );
  Z::Z (, );

which contains
void Y::Y (struct Y * const this, const struct Y & D.11498)
{
  *this = {CLOBBER};
  {
_1 = >x;
_2 = >x;
X::X (_1, _2);
this->o = D.11498->o;
  }

so the std::optional<> is simply aggregate copied, accessing any not
engaged member.

GCC is correct in diagnosing this uninitialized access.