[Bug c++/109480] [11/12/13 Regression] non-depedent access goes wrong in a template method sometimes since r11-1350-g92bed036098928

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-12
Summary|[11/12/13 Regression]   |[11/12/13 Regression]
   |non-depedent access goes|non-depedent access goes
   |wrong in a template method  |wrong in a template method
   |sometimes   |sometimes since
   ||r11-1350-g92bed036098928

--- Comment #3 from Martin Liška  ---
(In reply to Andrew Pinski from comment #2)
> Most likely this was caused by r11-1350 .

Yes.

[Bug bootstrap/109460] Build gcc for win32 failed in gcc13 master branch

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Costas Argyris  ---
What is the version of the cross-compiler, cross-binutils and make that you are
using to build gcc for windows from linux?

[Bug tree-optimization/109434] [12 Regression] std::optional weird -Wmaybe-unitialized and behaviour with -O2

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0
Summary|[12/13 Regression]  |[12 Regression]
   |std::optional weird |std::optional weird
   |-Wmaybe-unitialized and |-Wmaybe-unitialized and
   |behaviour with -O2  |behaviour with -O2
  Known to fail||12.2.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2) when building xdvik

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|FIXED   |---
   Target Milestone|13.0|12.3
 Status|RESOLVED|ASSIGNED
   Priority|P3  |P2

--- Comment #11 from Richard Biener  ---
On a 2nd thought I'm going to backport it for 12.3.

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2) when building xdvik

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Keywords||ice-checking,
   ||ice-on-valid-code

--- Comment #10 from Richard Biener  ---
Fixed (but latent).

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2) when building xdvik

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

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

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

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

commit r13-7144-g2d7ad38707e1fd71193d440198cc0726092b9015
Author: Richard Biener 
Date:   Tue Apr 11 16:06:12 2023 +0200

tree-optimization/109469 - SLP with returns-twice region start

The following avoids an SLP region starting with a returns-twice
call where we cannot insert stmts at the head.

PR tree-optimization/109469
* tree-vect-slp.cc (vect_slp_function): Skip region starts with
a returns-twice call.

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

[Bug tree-optimization/109434] [12/13 Regression] std::optional weird -Wmaybe-unitialized and behaviour with -O2

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

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

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

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

commit r13-7143-g6e3e708dbadaae7b504af7fc4410015624793f02
Author: Richard Biener 
Date:   Tue Apr 11 15:06:59 2023 +0200

tree-optimization/109434 - bogus DSE of throwing call LHS

The byte tracking of call LHS didn't properly handle possibly
throwing calls correctly which cases bogus DSE and in turn, for the
testcase a bogus uninit diagnostic and (unreliable) wrong-code.

PR tree-optimization/109434
* tree-ssa-dse.cc (initialize_ao_ref_for_dse): Properly
handle possibly throwing calls when processing the LHS
and may-defs are not OK.

* g++.dg/opt/pr109434.C: New testcase.

[Bug target/109479] [RISC-V] Build vint64m1_t with rv64gc_zve32x_zvl64b should promote information like "vint64m1_t requires the 'zve64x' extensions"

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #5 from Li Pan  ---
Thanks kito, update the title for clarification.

[Bug target/109479] [RISC-V] Build vint64m1_t with rv64gc_zve32x_zvl64b should promote information like "vint64m1_t requires the 'zve64x' extensions"

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #4 from JuzheZhong  ---
Thanks for reporting it. Will fix soon today or tomorrow.

[Bug target/109479] [RISC-V] Build with rv64gc_zve32x_zvl64b should fail but actually not

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

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

Kito Cheng  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-12

--- Comment #3 from Kito Cheng  ---
Title might little bit misleading, -march=rv64gc_zve32x_zvl64b is valid arch
configuration, invalid thing is vint64m*_t and vuint64m*_t are invalid for
rv64gc_zve32x.

[Bug target/109479] [RISC-V] Build with rv64gc_zve32x_zvl64b should fail but actually not

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #2 from Li Pan  ---
Thanks for reminding me. Sorry for missing that and will pay more attention to
this next time.

The test case.

#include "riscv_vector.h"

vint64m1_t foo ()
{
vint64m1_t v;
return v;
}

According to the RVV SPEC below, the 'vint64m1_t' (aka '__rvv_int64m1_t')
requires the 'zve64x' extensions.

https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#18-standard-vector-extensions

[Bug c++/109480] [11/12/13 Regression] non-depedent access goes wrong in a template method sometimes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.4

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2) when building xdvik

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

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

--- Comment #8 from Alexander Monakov  ---
*** Bug 109477 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/109477] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 8) when building busybox

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

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #4 from Alexander Monakov  ---
This is also SLP emitting a vector ctor in an unexpected place, just like in
PR109469, so I'll go ahead and mark it as a dup. Thanks for the report.

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

[Bug c++/109480] [11/12/13 Regression] non-depedent access goes wrong in a template method sometimes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=41437
   Keywords||rejects-valid
Summary|g++-12 and g++-11 failed to |[11/12/13 Regression]
   |compile the attached source |non-depedent access goes
   |file while g++-10 and clang |wrong in a template method
   |can.|sometimes

--- Comment #2 from Andrew Pinski  ---
Most likely this was caused by r11-1350 .

Reduced further:
```
template  struct s {
protected:
  bool g();
  void f();
  //template  friend struct s;
};
template 
void s::f()  {
  s l;
  const bool b = l.g();
}
```

This means also s::f would be the only valid specialization here too.

[Bug c++/109480] g++-12 and g++-11 failed to compile the attached source file while g++-10 and clang can.

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

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

--- Comment #1 from Andrew Pinski  ---
Adding:

template  friend struct RemoteAccessibleBase;

To the RemoteAccessibleBase template struct fixes the issue 

[Bug c++/109480] New: g++-12 and g++-11 failed to compile the attached source file while g++-10 and clang can.

[ishikawa at yk dot rim.or.jp via Gcc-bugs]

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

Bug ID: 109480
   Summary: g++-12 and g++-11 failed to compile the attached
source file while g++-10 and clang can.
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishikawa at yk dot rim.or.jp
  Target Milestone: ---

Created attachment 54837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54837&action=edit
target.cpp:  this shows the compiler issue for g++-10 and g++-11

I am reporting a reduced case of a compilation issue noticed when we compile
mozilla firefox browser, and thunderbird mail client software.
For the original problem report and the workaround (basically rewriting the
source code), see the bugzilla entry at mozilla's bugzilla, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1825516

Now, I am a newbie to c-vise source coded reduction tool, but managed to create
the attached reduced source file.
That file shows the symptom.

I am using the following compiler for testing.
Version Info:
g++-10 --version
g++-10 (Debian 10.4.0-7) 10.4.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-11 --version
g++-11 (Debian 11.3.0-12) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-12 --version
g++-12 (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ clang --version
clang version 15.0.5 (taskcluster-ETTsfeYjQ76jbYk0xzOrPA)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/ishikawa/.mozbuild/clang/bin


The clang compiler I use is a version compiled by mozilla to facilitate that
the developer community uses the same clang everywhere.

g++-10 can compile it.
g++-11 can not.
g++-12 can not.
clang can.
See the console log below.

ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-10 -c target.cpp
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-11 -c target.cpp
target.cpp: In member function ‘void
mozilla::a11y::RemoteAccessibleBase::BoundsWithOffset() const’:
target.cpp:14:57: error: ‘bool
mozilla::a11y::RemoteAccessibleBase::ApplyScrollOffset(nsRect&) const
[with Derived = mozilla::a11y::RemoteAccessible]’ is protected within this
context
   14 |   const bool hasScrollArea = remoteAcc.ApplyScrollOffset(bounds);
  |  ~~~^~~~
target.cpp:6:14: note: declared protected here
6 | bool ApplyScrollOffset(nsRect & a) const { return a.x > 0 ?
true: false; } ;
  |  ^
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ g++-12 -c target.cpp
target.cpp: In member function ‘void
mozilla::a11y::RemoteAccessibleBase::BoundsWithOffset() const’:
target.cpp:14:57: error: ‘bool
mozilla::a11y::RemoteAccessibleBase::ApplyScrollOffset(nsRect&) const
[with Derived = mozilla::a11y::RemoteAccessible]’ is protected within this
context
   14 |   const bool hasScrollArea = remoteAcc.ApplyScrollOffset(bounds);
  |  ~~~^~~~
target.cpp:6:14: note: declared protected here
6 | bool ApplyScrollOffset(nsRect & a) const { return a.x > 0 ?
true: false; } ;
  |  ^
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ clang -c target.cpp
ishikawa@ip030:~/Dropbox/TB-DIR/WALL-PATCH-DIR$ 


Thank you for sharing the great compiler suite with the developer community.

[Bug target/108815] gcc.target/powerpc/pr83677.c fails on power 9 BE

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #3 from Kewen Lin  ---
Fixed on trunk, no backports needed.

[Bug target/109479] [RISC-V] Build with rv64gc_zve32x_zvl64b should fail but actually not

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 54836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54836&action=edit
testcase

Next time please attach or put inline the testcase instead of just linking to
godbolt. Also you should put why it should fail instead of just saying it
should fail because clang says it fails.

[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed

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

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

--- Comment #5 from Sam James  ---
(In reply to Jakub Jelinek from comment #4)
> PR108783?

Test case was from it. I don't mind not adding such things to See Also though,
I'm still new to bug wrangling. Sorry if it's wrong!

[Bug c/109479] New: [RISC-V] Build with rv64gc_zve32x_zvl64b should fail but actually not

[pan2.li at intel dot com via Gcc-bugs]

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

Bug ID: 109479
   Summary: [RISC-V] Build with rv64gc_zve32x_zvl64b should fail
but actually not
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pan2.li at intel dot com
  Target Milestone: ---

When compiling with option '-march=rv64gc_zve32x_zvl64b', it should report an
error similar to clang, you can see this case in below link.

https://godbolt.org/z/qn1bcK7Pn

[Bug bootstrap/109460] Build gcc for win32 failed in gcc13 master branch

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

--- Comment #13 from Huaqi  ---
Hello, I didn't take a try with other mingw gcc version, locally I just revert
304c7d44a2212e6fd618587331cea2c266dc10bf commit, then it works for me.

Thanks
Huaqi

[Bug bootstrap/109460] Build gcc for win32 failed in gcc13 master branch

[fanghuaqi at vip dot qq.com via Gcc-bugs]

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

--- Comment #12 from Huaqi  ---
Hello, this is the command used to configure gcc

/work/gcc/configure --target=riscv64-unknown-elf --host=i686-w64-mingw32
--prefix=/work/LocalInstall/win32/newlibc/2023.04-eng2/gcc --disable-shared
--di
sable-threads --enable-languages=c,c++ --with-pkgversion=g465fcab6ea9
--with-system-zlib --enable-tls --with-newlib
--with-sysroot=/work/LocalInstall/win32/n
ewlibc/2023.04-eng2/gcc/riscv64-unknown-elf
--with-native-system-header-dir=/include --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-li
bgomp --disable-nls --disable-tm-clone-registry --src=/work/gcc
--enable-multilib
--with-multilib-generator=rv32emc-ilp32e--;rv32emac-ilp32e--;rv32imc-ilp32-
-;rv32imac-ilp32--;rv32imafc-ilp32f--;rv32imafdc-ilp32d--;rv32imac_zba_zbb_zbc_zbs-ilp32--;rv32imafc_zba_zbb_zbc_zbs-ilp32f--;rv32imafdc_zba_zbb_zbc_zbs-ilp3
2d--;rv64imac-lp64--;rv64imafc-lp64f--;rv64imafdc-lp64d--;rv64imac_zba_zbb_zbc_zbs-lp64--;rv64imafc_zba_zbb_zbc_zbs-lp64f--;rv64imafdc_zba_zbb_zbc_zbs-lp64d-
-; --with-abi=lp64 --with-arch=rv64ima --with-tune=rocket --with-isa-spec=2.2
CFLAGS_FOR_TARGET=-Os   -mcmodel=medany CXXFLAGS_FOR_TARGET=-Os   -mcmodel=meda
ny

and then do command below

make

[Bug target/108815] gcc.target/powerpc/pr83677.c fails on power 9 BE

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:5582ad0afb051a76231b2959487f4ef1746df283

commit r13-7142-g5582ad0afb051a76231b2959487f4ef1746df283
Author: Kewen Lin 
Date:   Tue Apr 11 21:51:40 2023 -0500

testsuite: Adjust powerpc pr83677.c for BE [PR108815]

The test case gcc.target/powerpc/pr83677.c was written for
LE environment, this patch is to make it work on BE as well.

PR testsuite/108815

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr83677.c (v_expand_u8, v_expand_u16,
v_load_deinterleave_f32, v_store_interleave_f32): Adjust some code
by
considering BE.

[Bug libstdc++/109474] chunk_by doesn't work for ranges of proxy references

[barry.revzin at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Barry Revzin  ---
Serves me right for only checking vector (which worked) and vector
(which didn't) and not bothering to check vector const (which also doesn't
work) and thus overly complicating the bug report.

I got too excited that vector played an important role I guess.

[Bug rtl-optimization/109478] New: FAIL: g++.dg/other/pr104989.C -std=gnu++14 (internal compiler error: Segmentation fault)

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

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

Bug ID: 109478
   Summary: FAIL: g++.dg/other/pr104989.C  -std=gnu++14 (internal
compiler error: Segmentation fault)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B
/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/other/pr104989.C
-fdiagnostics-plain-output -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++14 -fnon-call-exceptions -S -o pr104989.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/other/pr104989.C:6:9: warning:
width of 'a::b' exceeds its type
during RTL pass: expand
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/other/pr104989.C: In function 'void
c(...)':
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/other/pr104989.C:8:16: internal
compiler error: Segmentation fault
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
compiler exited with status 1
FAIL: g++.dg/other/pr104989.C  -std=gnu++14 (internal compiler error:
Segmentation fault)
XFAIL: g++.dg/other/pr104989.C  -std=gnu++14 (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/other/pr104989.C:6:9: warning:
width of 'a::b' exceeds its type
during RTL pass: expand
/home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/other/pr104989.C:8:16: internal
compiler error: Segmentation fault

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Andrew Macleod  ---
Created attachment 54835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54835&action=edit
in progress patch

THe fix for PR 108139 disallowed an equivalences with a PHI because it may be a
one way equivalence. The PHI may be an equivalence via UNDEFINED arguments so
PHIDEF == name, but name may not be == PHIDEF.

We were checking if the equivalence was a PHI node, buit we were not checking
if the current NAME was a phi node.  SO in this case, 

# Result$16_552 = PHI <_143(160), Result$16_453(D)(158)>

we are evaluating Result$16_552, so the check for _143 from that PR was no
triggering. I think we probably need to also check if the name we are
evaluating is a PHI node as well.

Patch is in testing. I do not know if it fixes the execution test or not, but
it removes the problematic code we were looking at.

[Bug tree-optimization/109477] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 8) when building busybox

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

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

--- Comment #3 from Sam James  ---
See also PR109469 and PR109410.

[Bug tree-optimization/109477] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 8) when building busybox

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

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

--- Comment #2 from Sam James  ---
Created attachment 54834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54834&action=edit
wget.i (reduced further, cleaned up, check)

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
In DOM3 I see
901970   range_on_entry (Result$16_552) to BB 120
<...>
Equivalence update! :  _143 has range  :  [irange] TokenKind [22, 22] NONZERO
0x16 refining range to :[irange] TokenKind [22, 22] NONZERO 0x16
 TRUE : (901970) range_on_entry (Result$16_552) [irange] TokenKind [22,
22] NONZERO 0x16

Because it thinks they are equivlaence, its refining the range to [22,22] which
is the value of _143 on that edge
this traces back to evaluating :

# Result$16_552 = PHI <_143(160), Result$16_453(D)(158)>
where we create an equivalence between Result$16_552 and _143 from bb160.

The reason it is creating the equivalence  is because the value of
Result$16_453(D) is undefined.  It is a local automatic with no initial value. 
When evaluating PHIS, if an incoming range is UNDEFINED, we ignore that
edge/value as it can be anything we choose.
We choose to make it the same as the other argument which allows us to create
an equivlaence between the two.

unsigned short Result$16;

So this boils down to using an uninitialized value for Result$16.

Now the question is where did that come from.

void EmptyLocalizationContextChecker::MethodCrawler::VisitObjCMessageExpr
<...>
  Token Result;
  int p_count = 0;
  while (!TheLexer.LexFromRawLexer(I)) {
if (I.getKind() == tok::l_paren)
  ++p_count;
if (I.getKind() == tok::r_paren) {
  if (p_count == 1)
break;
  --p_count;
}
Result = I;
  }

IF the While loop does not execute, then result will be undefined on that edge.
 The code leading to this PHI node is 

 [local count: 488466924]:
  if (_143 == 22)
goto ; [70.13%]
  else
goto ; [29.87%]

   [local count: 251634481]:
  if (p_count_732 == 1)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 237794584]:
  p_count_88 = p_count_732 + -1;

   [local count: 726261510]:
  # p_count_45 = PHI 
  Result$UintData_449 = MEM  [(struct Token *)&I + 4B];
  Result$PtrData_172 = MEM  [(struct Token *)&I + 8B];
  _439 = TheLexer.D.700857.LexingRawMode;
  if (_439 != 0)
goto ; [99.96%]
  else
goto ; [0.04%]

   [local count: 725971006]:


So on the path to BB 160 comes from 122 which can come from 119,121 or 118.  It
seems to be using the path oracle and following a path which comes
119->120->121->122->160.And on that path, the range is indeed [22, 22],
when it ignores the undefined possibility.

Still unclear if this is wrong or not here, and if it is, whetehr ti went wrong
earlier or not.  still analyzing

[Bug tree-optimization/109477] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 8) when building busybox

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

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

--- Comment #1 from Sam James  ---
Created attachment 54833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54833&action=edit
wget.i (reduced)

[Bug fortran/104312] ICE with -ff2c in fold_convert_loc, at fold-const.cc:2451

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2023-April/059167.html

[Bug tree-optimization/109477] New: [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 8) when building busybox

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

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

Bug ID: 109477
   Summary: [13 regression] ICE: internal compiler error:
verify_flow_info failed (error: returns_twice call is
not first in basic block 8) when building busybox
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 54832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54832&action=edit
wget.i.orig

Hit this when building busybox-1.34.1 w/ 13.0.1 20230409 with checking.

```
x86_64-pc-linux-gnu-gcc -Wp,-MD,networking/.wget.o.d  -std=gnu99 -Iinclude
-Ilibbb  -include include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DBB_VER='"1.34.1"' -O2 -pipe
-march=native -fdiagnostics-color=always -frecord-gcc-switches -Wreturn-type
-fno-strict-aliasing -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes
-Wunused -Wunused-parameter -Wunused-function -Wunused-value
-Wmissing-prototypes -Wmissing-declarations -Wno-format-security
-Wdeclaration-after-statement -Wold-style-definition -finline-limit=0
-fno-builtin-strlen -ffunction-sections -fdata-sections
-fno-guess-branch-probability -funsigned-char -fno-unwind-tables
-fno-asynchronous-unwind-tables -fno-builtin-printf   
-DKBUILD_BASENAME='"wget"'  -DKBUILD_MODNAME='"wget"' -c -o networking/wget.o
networking/wget.c
networking/wget.c: In function ‘spawn_https_helper_openssl’:
networking/wget.c:666:12: error: returns_twice call is not first in basic block
8
  666 | static int spawn_https_helper_openssl(const char *host, unsigned port)
  |^~
bb__xvfork_pid_45 = vfork ();
during GIMPLE pass: slp
networking/wget.c:666:12: internal compiler error: verify_flow_info failed
0x7acafb verify_flow_info()
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/cfghooks.cc:285
0x1523abd execute_function_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:2110
0x1489c51 do_per_function
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:1694
0x1489c51 execute_todo
   
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r1/gcc-13-20230409/gcc/passes.cc:2152
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.
```

[Bug target/109476] Missing optimization for 8bit/8bit multiplication / regression

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Wilhelm M  ---
Inetristingly changing the function to 


uint16_t mul(const uint8_t a, const uint16_t b) {
return static_cast((b >> 8) + 1) * a ;
}

produces optimal

mul(unsigned char, unsigned int):
subi r23,lo8(-(1))
mul r23,r24
movw r24,r0
clr __zero_reg__
ret

[Bug c++/109476] New: Missing optimization for 8bit/8bit multiplication / regression

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

Bug ID: 109476
   Summary: Missing optimization for 8bit/8bit multiplication /
regression
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: klaus.doldinger64 at googlemail dot com
  Target Milestone: ---

For avr-gcc > 4.6.4 the follwing function

uint16_t mul(const uint8_t a, const uint16_t b) {
return static_cast((b >> 8) + 0) * a ;
}

produces suboptimal

mul(unsigned char, unsigned int):
mov r18,r23
ldi r19,0
mov r20,r24
mul r20,r18
movw r24,r0
mul r20,r19
add r25,r0
clr __zero_reg__
ret

whereas avr-gcc 4.6.4 produces optimal

mul(unsigned char, unsigned int):
mul r23,r24
movw r24,r0
clr r1
ret

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

[jorge.pinto.sousa at proton dot me via Gcc-bugs]

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

--- Comment #6 from Jorge Pinto Sousa  ---
Let me rephrase, Im sorry maybe I was too broad. For any specific gcc binary,

> /usr/bin/gcc-8 -Q --help=warnings | grep enabled

Will give me the list of warnings enabled by default?

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

[jorge.pinto.sousa at proton dot me via Gcc-bugs]

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

Jorge Pinto Sousa  changed:

   What|Removed |Added

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

--- Comment #5 from Jorge Pinto Sousa  ---
> You get the trigraph warning if you don't supply any options. -std=c++14 
> option > enables -trigraphs option

Ok so to have it enabled again I need to -Wtrigraphs after.

So:
>  /usr/bin/gcc-8 -Q --help=warnings | grep enabled

This should give the list of warnings enabled for that specific gcc binary?

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jorge Pinto Sousa from comment #2)
> Can you point me where, or by what option, when building from source are those
> enabled?

You should ask the distro for that support.


Also -Wctor-dtor-privacy is not enabled by default either.


apinski@xeond:~/src/upstream-gcc/gcc/gcc$ ~/upstream-gcc/bin/gcc -Q
--help=warning | grep ctor-dtor-privacy
  -Wctor-dtor-privacy   [available in C++, ObjC++]




https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Warning-Options.html#index-Wtrigraphs
Says:
If -Wall is not given, this option is still enabled unless trigraphs are
enabled. 

Which exactly what -std=c++14 does, it enables them.

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

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

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

--- Comment #3 from Andrew Pinski  ---
>but then some warnings despite being listed there were not triggered:
https://godbolt.org/z/GGnjcjxKh


You get the trigraph warning if you don't supply any options. -std=c++14 option
enables -trigraphs option

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

[jorge.pinto.sousa at proton dot me via Gcc-bugs]

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

--- Comment #2 from Jorge Pinto Sousa  ---
> No in fact -Wformat-security is not enabled by default in the released 
> version of GCC from the FSF, the distro I know that enables it by default is 
> both Debian and Ubuntu.

Ah so the ones that come enabled by default are distro dependent. Can you point
me where, or by what option, when building from source are those enabled?

[Bug other/109475] How to check for default compiler warnings in g++ 8.4.0

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

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

--- Comment #1 from Andrew Pinski  ---
>So we can say that these are the only two that are default enabled?


No in fact -Wformat-security is not enabled by default in the released version
of GCC from the FSF, the distro I know that enables it by default is both
Debian and Ubuntu.

[Bug other/109475] New: How to check for default compiler warnings in g++ 8.4.0

[jorge.pinto.sousa at proton dot me via Gcc-bugs]

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

Bug ID: 109475
   Summary: How to check for default compiler warnings in g++
8.4.0
   Product: gcc
   Version: 8.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jorge.pinto.sousa at proton dot me
  Target Milestone: ---

Hello,

I was trying to get the list of warnings enabled by default from gcc and where
to get that info from. Looked in to the manual and found that we could get a
list of the warnings enabled by doing:

>  /usr/bin/gcc-8 -Q --help=warnings | grep enabled
but then some warnings despite being listed there were not triggered:
https://godbolt.org/z/GGnjcjxKh

Like -Wtrigraphs for example:
> gcc -Q --help=warning | grep trigraph 
>   -Wtrigraphs   [enabled]

I then tried to compile that example locally by dumping all the flags:

>  gcc -Q -v foo.cpp
which (I think) dumps (all) the compilation and linking flags, and the only
warnings I got there are:

> options passed:  -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE foo.cpp
> -mtune=generic -march=x86-64 -Wctor-dtor-privacy
> -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
> -Wformat-security -fstack-clash-protection -fcf-protection
> options enabled:  -fPIC -fPIE -faggressive-loop-optimizations
> (...)


That is :
> -Wformat 
> -Wformat-security 

So we can say that these are the only two that are default enabled?
(I also looked into
https://gcc.gnu.org/onlinedocs/gcc-8.4.0/gcc/Option-Summary.html but could not
find any pointers).

Would like to know where one can get the correct list for these. Note that I am
not talking about -Wall or anything. Just the list of warnings that is enabled
by default, without adding any other flags.

[Bug lto/109369] LTO drops explicitly referenced symbol _pei386_runtime_relocator

[pali at kernel dot org via Gcc-bugs]

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

--- Comment #8 from Pali Rohár  ---
So from the discussion, do I understand correctly that this is rather LD linker
issue?

[Bug libstdc++/108291] chunk_­by_­view::find-next/find-prev uses wrong lambda helper

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug libstdc++/108291] chunk_­by_­view::find-next/find-prev uses wrong lambda helper

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-11
 Status|UNCONFIRMED |ASSIGNED

[Bug libstdc++/109474] chunk_by doesn't work for ranges of proxy references

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
D'oh, thanks for the bug report.  Looks like a dup of PR108291, which
unfortunately slipped through the cracks..

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

[Bug libstdc++/108291] chunk_­by_­view::find-next/find-prev uses wrong lambda helper

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #1 from Patrick Palka  ---
*** Bug 109474 has been marked as a duplicate of this bug. ***

[Bug libstdc++/109474] New: chunk_by doesn't work for ranges of proxy references

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 109474
   Summary: chunk_by doesn't work for ranges of proxy references
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced example from Conor's tweet
(https://twitter.com/code_report/status/1645831980473282560):

#include 
#include 

void f(std::vector v) {
auto z = std::views::chunk_by(
v,
[](auto&& lhs, auto&& rhs){
return true;
});
auto i = z.begin();
}

This fails because the find_next implementation right now
(https://github.com/gcc-mirror/gcc/blob/0c5e64c4249322a178e1a0e843874e4d6b43b992/libstdc%2B%2B-v3/include/std/ranges#L6741-L6750)
passes a predicate into adjacent_find that requires both parameters be the same
type, but in this case indirect_binary_predicate is checking that it's
invocable with both value_type& (bool&) and reference
(vector::reference), which in this case are different types.

The original example was a zip_view of two ranges - which likewise would have
value_type& and reference be different.

[Bug target/96882] Wrong assembly code generated with arm-none-eabi-gcc -flto -mfloat-abi=hard options

[dcrocker at eschertech dot com via Gcc-bugs]

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

--- Comment #11 from David Crocker  ---
As the master branch was updated a year ago according to comment 10, does this
mean that there is now a stable release of gcc that incudes the patch?

[Bug target/65010] ppc backend generates unnecessary signed extension

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

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

Ajit Kumar Agarwal  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||aagarwa at gcc dot gnu.org

[Bug target/103784] suboptimal code for returning bool value on target ppc

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

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

Ajit Kumar Agarwal  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-04-11
 Status|UNCONFIRMED |ASSIGNED

[Bug middle-end/41742] Unnecessary zero-extension at -O2 but not -O1

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

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

Ajit Kumar Agarwal  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug middle-end/82940] Suboptimal code for (a & 0x7f) | (b & 0x80) on powerpc

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

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

Ajit Kumar Agarwal  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang

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

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

--- Comment #13 from Alex Coplan  ---
Clang recognizes the "cxx_defaulted_functions" feature to detect whether "=
default" functions are supported.

It's clear that __has_feature (cxx_defaulted_functions) should evaluate to 1
for -std=c++11 and above. It's less clear whether GCC intends to support "=
default" functions in C++98 mode as an extension, and therefore whether
__has_extension (cxx_defaulted_functions) should evaluate to 1 with -std=c++98.

I noticed that e.g. we accept:

struct S {
int x;
S(int a) : x(a) {}
S() = default;
};
void f() {
S s;
}

with -std=c++98 and emit a -Wc++11-extensions warning. This suggests that "=
default" might be supported as an extension, but it's not clear. By contrast,
it seems that deleted functions (detected with "cxx_deleted_functions") aren't
supported in C++98 mode, since e.g.

struct S {
S() = delete;
};
void f() {
S s;
}

doesn't get rejected with -std=c++98. It would be good to get some input from
C++ maintainers on the cxx_defaulted_functions case.

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

Bug 98450 Summary: Inconsistent Wunused-variable warning for std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98450

   What|Removed |Added

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

[Bug c++/98450] Inconsistent Wunused-variable warning for std::array

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

maic  changed:

   What|Removed |Added

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

--- Comment #3 from maic  ---
Fixed in 

# gcc --version 
gcc (GCC) 13.0.1 20230404 (Red Hat 13.0.1-0)

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

--- Comment #30 from maic  ---
This bug still exists for our project. To reproduce:


# g++ --version 
g++ (GCC) 13.0.1 20230404 (Red Hat 13.0.1-0)


# cat /tmp/2.cpp 
const int &Select(const int &i, const bool &b) { return i; }
int main() {
  int a;
  const auto &b{Select(a, true)};
}


# g++ -Wdangling-reference /tmp/2.cpp 
/tmp/2.cpp: In function ‘int main()’:
/tmp/2.cpp:4:15: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
4 |   const auto &b{Select(a, true)};
  |   ^
/tmp/2.cpp:4:23: note: the temporary was destroyed at the end of the full
expression ‘Select(a, true)’
4 |   const auto &b{Select(a, true)};
  | ~~^

[Bug tree-optimization/109473] [10/11/12/13 Regression] ICE during GIMPLE pass: vect: verify_gimple failed with -O1 -ftree-loop-vectorize

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |10.5
   Priority|P3  |P2
Summary|ICE during GIMPLE pass: |[10/11/12/13 Regression]
   |vect: verify_gimple failed  |ICE during GIMPLE pass:
   |with -O1|vect: verify_gimple failed
   |-ftree-loop-vectorize   |with -O1
   ||-ftree-loop-vectorize
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2023-04-11

--- Comment #2 from Jakub Jelinek  ---
Started with r10-4076-g82e8e335f917b9

[Bug fortran/61615] Failure to resolve correct generic with TYPE(C_PTR) arguments

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2023-April/059166.html

[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 CC||anlauf at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=61615
 Status|NEW |ASSIGNED

--- Comment #6 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2023-April/059166.html

[Bug tree-optimization/109473] ICE during GIMPLE pass: vect: verify_gimple failed with -O1 -ftree-loop-vectorize

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

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

Arsen Arsenović  changed:

   What|Removed |Added

Summary|ICE during GIMPLE pass: |ICE during GIMPLE pass:
   |vect: verify_gimple failed  |vect: verify_gimple failed
   |with -m32   |with -O1
   ||-ftree-loop-vectorize

--- Comment #1 from Arsen Arsenović  ---
oh, actually, it seems that the reduced case no longer requires -m32:

~/gcc/scratch_build/gcc$ ./cc1 -quiet ccGrpuMH.out -O1 -ftree-loop-vectorize
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘long unsigned int’
makes pointer from integer without a cast [-Wint-conversion]
   10 |   endptr = (__UINTPTR_TYPE__)endptr + buffers[i]->metas[j];
  |  ^
ccGrpuMH.out:11:16: warning: comparison of distinct pointer types lacks a cast
   11 | if (endptr > mem)
  |^
ccGrpuMH.out:4:6: error: invalid (pointer) operands ‘plus_expr’
4 | void do_port_use_buffers(struct spa_buffer **buffers) {
  |  ^~~
_110 = stmp_endptr_25.16_109 + endptr_17;
during GIMPLE pass: vect
ccGrpuMH.out:4:6: internal compiler error: verify_gimple failed
0x142f352 verify_gimple_in_cfg(function*, bool, bool)
../../scratch/gcc/tree-cfg.cc:5648
0x12d1050 execute_function_todo
../../scratch/gcc/passes.cc:2098
0x12d15be execute_todo
../../scratch/gcc/passes.cc:2152
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.
~/gcc/scratch_build/gcc 4 $ gcc-12 -x c ccGrpuMH.out -O1 -ftree-loop-vectorize
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘long unsigned int’
makes pointer from integer without a cast [-Wint-conversion]
   10 |   endptr = (__UINTPTR_TYPE__)endptr + buffers[i]->metas[j];
  |  ^
ccGrpuMH.out:11:16: warning: comparison of distinct pointer types lacks a cast
   11 | if (endptr > mem)
  |^
ccGrpuMH.out:4:6: error: invalid (pointer) operands ‘plus_expr’
4 | void do_port_use_buffers(struct spa_buffer **buffers) {
  |  ^~~
_108 = stmp_endptr_25.16_107 + endptr_17;
during GIMPLE pass: vect
ccGrpuMH.out:4:6: internal compiler error: verify_gimple failed
0xe96d34 verify_gimple_in_cfg(function*, bool)
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/tree-cfg.cc:5561
0xd5c927 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/passes.cc:2085
0xd5ca51 execute_todo
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/passes.cc:2139
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.

[Bug tree-optimization/81953] Code sinking increases register pressure

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

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #7 from Peter Bergner  ---
Ajit is going to start looking into this for us.

[Bug tree-optimization/109473] New: ICE during GIMPLE pass: vect: verify_gimple failed with -m32

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

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

Bug ID: 109473
   Summary: ICE during GIMPLE pass: vect: verify_gimple failed
with -m32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arsen at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54831&action=edit
reduced reproducer

detected initially while building PipeWire, the attached code compiled with
-m32 -march=x86-64 -O1 -ftree-loop-vectorize produces an ICE:

~/gcc/scratch_build/gcc 4 $ ./cc1 -quiet ccGrpuMH.out -m32 -march=x86-64 -O1
-ftree-loop-vectorize
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘unsigned int’ makes
pointer from integer without a cast [-Wint-conversion]
   10 |   endptr = (__UINTPTR_TYPE__)endptr + buffers[i]->metas[j];
  |  ^
ccGrpuMH.out:11:16: warning: comparison of distinct pointer types lacks a cast
   11 | if (endptr > mem)
  |^
ccGrpuMH.out:4:6: error: invalid (pointer) operands ‘plus_expr’
4 | void do_port_use_buffers(struct spa_buffer **buffers) {
  |  ^~~
_77 = stmp_endptr_23.18_76 + endptr_15;
during GIMPLE pass: vect
ccGrpuMH.out:4:6: internal compiler error: verify_gimple failed
0x142f352 verify_gimple_in_cfg(function*, bool, bool)
../../scratch/gcc/tree-cfg.cc:5648
0x12d1050 execute_function_todo
../../scratch/gcc/passes.cc:2098
0x12d15be execute_todo
../../scratch/gcc/passes.cc:2152
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

~/gcc/scratch_build/gcc 4 $ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../scratch/configure --disable-bootstrap
--enable-checking=yes,rtl,tree --enable-languages=c,c++ --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230411 (experimental) (GCC)
~/gcc/scratch_build/gcc$ echo -n g:; git -C ../../scratch rev-parse HEAD^
g:b8e32978e3d9e3b88cd4f441edfdebfa395a5c26

(the commit applied on top of this is a maintainer-scripts/ edit)

I don't have a vanilla build of current releases/gcc-12, but it seems that it
is affected too:

~/gcc/scratch_build/gcc 1 $ gcc-12 --version
gcc-12 (Gentoo Hardened 12.2.1_p20230408 p14) 12.2.1 20230408
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~/gcc/scratch_build/gcc$ gcc-12 -x c -S -o - ccGrpuMH.out -m32 -march=x86-64
-O1 -ftree-loop-vectorize
.file   "ccGrpuMH.out"
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘unsigned int’ makes
pointer from integer without a cast [-Wint-conversion]
   10 |   endptr = (__UINTPTR_TYPE__)endptr + buffers[i]->metas[j];
  |  ^
ccGrpuMH.out:11:16: warning: comparison of distinct pointer types lacks a cast
   11 | if (endptr > mem)
  |^
.text
ccGrpuMH.out:4:6: error: invalid (pointer) operands ‘plus_expr’
4 | void do_port_use_buffers(struct spa_buffer **buffers) {
  |  ^~~
_77 = stmp_endptr_23.18_76 + endptr_15;
during GIMPLE pass: vect
ccGrpuMH.out:4:6: internal compiler error: verify_gimple failed
0xe96d34 verify_gimple_in_cfg(function*, bool)
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/tree-cfg.cc:5561
0xd5c927 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/passes.cc:2085
0xd5ca51 execute_todo
   
/usr/src/debug/sys-devel/gcc-12.2.1_p20230408/gcc-12-20230408/gcc/passes.cc:2139
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.

but, earlier gcc-12 seems unaffected:
~/gcc/releases/gcc-12b/gcc$ ./cc1 -quiet ccGrpuMH.out -m32 -march=x86-64 -O1
-ftree-loop-vectorize
ccGrpuMH.out: In function ‘do_port_use_buffers’:
ccGrpuMH.out:9:14: warning: comparison between pointer and integer
9 | for (; j < buffers; j++)
  |  ^
ccGrpuMH.out:10:14: warning: assignment to ‘void *’ from ‘unsigne

[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed

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

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

--- Comment #4 from Jakub Jelinek  ---
PR108783?
Anyway, will have a look now.

[Bug ada/109472] New: [13 regression] False unread/unassigned warning for variable in local package

[simon at pushface dot org via Gcc-bugs]

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

Bug ID: 109472
   Summary: [13 regression] False unread/unassigned warning for
variable in local package
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54830&action=edit
Demonstrator

The compiler warns that a variable in a local package is not assigned and not
read, even though it is assigned and read in code outside the package.

GNAT 13.0.1 20230409 (experimental)
Copyright 1992-2023, Free Software Foundation, Inc.

Compiling: test_wu.adb
Source file time stamp: 2023-04-11 14:20:32
Compiled at: 2023-04-11 15:30:49

 1. procedure Test_Wu is
 2.
 3.   package P is
 4. X : Integer;
|
>>> warning: variable "X" is never read and never assigned [-gnatwu]

 5.   end;
 6.
 7.   Y : Integer;
 8.
 9. begin
10.   P.X := 5;
11.   Y := P.X;
12. end;

 12 lines: No errors, 1 warning

[Bug target/109067] Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit.

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

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Meissner  ---
Trunk patched on March 20th, 2023.
Gcc 12 patched on April 10th, 2023.
Gcc 11 patched on April 11th, 2023.

[Bug target/109067] Powerpc GCC does not support __ibm128 complex multiply/divide if long double is IEEE 128-bit.

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Michael Meissner
:

https://gcc.gnu.org/g:5a15a78b919c43954fbfcc90f53f34d7e2700c97

commit r11-10618-g5a15a78b919c43954fbfcc90f53f34d7e2700c97
Author: Michael Meissner 
Date:   Tue Apr 11 10:11:53 2023 -0400

Backport from master

2023-04-11  Michael Meissner  

gcc/

PR target/109067
* config/rs6000/rs6000.c (create_complex_muldiv): Delete.
(init_float128_ieee): Delete code to switch complex multiply and
divide
for long double.  Backport from master, 3/20/2023.
(complex_multiply_builtin_code): New helper function.
(complex_divide_builtin_code): Likewise.
(rs6000_mangle_decl_assembler_name): Add support for mangling the
name
of complex 128-bit multiply and divide built-in functions.

gcc/testsuite/

PR target/109067
* gcc.target/powerpc/divic3-1.c: New test.  Backport from master,
3/20/2023.
* gcc.target/powerpc/divic3-2.c: Likewise.
* gcc.target/powerpc/mulic3-1.c: Likewise.
* gcc.target/powerpc/mulic3-2.c: Likewise.

[Bug target/109104] [13 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1171 with -fzero-call-used-regs=all -march=rv64gv

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

https://gcc.gnu.org/g:40fc8e3d4f600d89e6b065d6f12db7a816269c8f

commit r13-7138-g40fc8e3d4f600d89e6b065d6f12db7a816269c8f
Author: Yanzhang Wang 
Date:   Tue Apr 11 19:37:48 2023 +0800

RISC-V: Fix regression of -fzero-call-used-regs=all [PR109104]

This patch registers a riscv specific function to
TARGET_ZERO_CALL_USED_REGS instead of default in targhooks.cc. It will
clean gpr and vector relevant registers.

gcc/ChangeLog:

PR target/109104
* config/riscv/riscv-protos.h (emit_hard_vlmax_vsetvl): New.
* config/riscv/riscv-v.cc (emit_hard_vlmax_vsetvl): New.
(emit_vlmax_vsetvl): Use emit_hard_vlmax_vsetvl.
* config/riscv/riscv.cc (vector_zero_call_used_regs): New.
(riscv_zero_call_used_regs): New.
(TARGET_ZERO_CALL_USED_REGS): New.

gcc/testsuite/ChangeLog:

PR target/109104
* gcc.target/riscv/zero-scratch-regs-1.c: New test.
* gcc.target/riscv/zero-scratch-regs-2.c: New test.
* gcc.target/riscv/zero-scratch-regs-3.c: New test.

Signed-off-by: Yanzhang Wang 
Co-authored-by: Pan Li 
Co-authored-by: Ju-Zhe Zhong 
Co-authored-by: Kito Cheng 

[Bug tree-optimization/109471] Missing loop unrolling for small std::array?

[stefano.d at posteo dot de via Gcc-bugs]

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

--- Comment #4 from Stefano  ---
Created attachment 54829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54829&action=edit
source code

[Bug tree-optimization/109471] Missing loop unrolling for small std::array?

[stefano.d at posteo dot de via Gcc-bugs]

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

--- Comment #3 from Stefano  ---
(In reply to Xi Ruoyao from comment #2)
> The code seems available in the godbolt link but it uses std::array, not
> std::vector.

I'm sorry. I mean std::array of course. :-/

[Bug tree-optimization/109471] Missing loop unrolling for small std::vector?

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #2 from Xi Ruoyao  ---
(In reply to Richard Biener from comment #1)
> I suppose both cases could be optimized the same, but we only do limited "IR
> interpretation" and only as side-effect of optimizing scalarized code, not
> simulated execution traces.
> 
> Needs some more investigation.
> 
> Can you please attach the source code?

The code seems available in the godbolt link but it uses std::array, not
std::vector.

[Bug tree-optimization/109471] Missing loop unrolling for small std::vector?

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c++ |tree-optimization

--- Comment #1 from Richard Biener  ---
I suppose both cases could be optimized the same, but we only do limited "IR
interpretation" and only as side-effect of optimizing scalarized code, not
simulated execution traces.

Needs some more investigation.

Can you please attach the source code?

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-04-11
 Ever confirmed|0   |1

--- Comment #7 from Richard Biener  ---
I will have a look.

[Bug testsuite/109466] [13 regression] gfortran.dg/gomp/affinity-clause-1.f90 fails after r13-7120-g46fe32cb4d887d

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||testsuite-fail
   Target Milestone|--- |13.0

[Bug tree-optimization/109442] Dead local copy of std::vector not removed from function

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

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

--- Comment #3 from Jonathan Wakely  ---
Ah, maybe the problem is that the library code manually elides destroying the
elements, precisely because it's a no-op. So we don't actually destroy the
elements, which means the compiler might think they're still initialized and so
could be inspected.

If the library explicitly does vec[i].~T() for every i then would that help?
The compiler would know there are no valid elements in the storage, and so
nothing operator delete could inspect.

We could continue to elide destroying the elements when !defined __OPTIMIZE__
so that we don't run a loop that does nothing, but with optimization enabled
rely on the compiler to remove that loop.

[Bug sanitizer/109446] Possible destination array overflow without diagnosis in memcpy

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-11
 Status|UNCONFIRMED |NEW

--- Comment #2 from Xi Ruoyao  ---
Should we disable __builtin_memcpy etc. with -fsanitize=address?

[Bug tree-optimization/109442] Dead local copy of std::vector not removed from function

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

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

--- Comment #2 from Jonathan Wakely  ---
Neither v nor v1 escapes the function, so I don't think operator delete can
inspect them.

The destructor doesn't inspect the contents, it just destroys the elements
(which is a no-op for int) and then calls operator delete to free the storage.

[Bug tree-optimization/109442] Dead local copy of std::vector not removed from function

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jwakely.gcc at gmail dot com,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-04-11
Version|unknown |13.0

--- Comment #1 from Richard Biener  ---
So we're failing to DSE

  _13 = pretmp_25 - pretmp_63;
  if (_13 > 4)
goto ; [97.30%]
  else
goto ; [2.70%]

   [local count: 14278734]:
  if (_13 == 4)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 913536322]:
  _23 = (long unsigned int) _13;
  __builtin_memmove (_37, pretmp_63, _23);
  goto ; [100.00%]

   [local count: 34511373]:
  _24 = *pretmp_63;
  *_37 = _24;

   [local count: 542742079]:
  operator delete (_37, _49);

because I think the DTOR / overloaded global delete might inspect the vector
contents.  So I'm not sure it would be valid to elide the memmove/store.
When the stores would be elided we'd DCE the new/delete pair as well.

[Bug tree-optimization/109441] missed optimization when all elements of vector are known

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Version|unknown |13.0
 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Well, it doesn't need std::vector for this, a C testcase with a large enough
array (> 16 elements, the unroll limit) suffers from the same "problem".

But IMHO it's academic, right?

GCC only transforms loopy code like you suggest by complete peeling of the
loop, it doesn't attempt to "simulate" IL (and if, then it would only up
to some complexity limit).

[Bug tree-optimization/109440] Missed optimization of vector::at when a function is called inside the loop

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

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

--- Comment #2 from Richard Biener  ---
There's that other bug which would be basically a duplicate, so I leave this
one tree-optimization, not C++.

[Bug tree-optimization/109469] [13 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
Not a dup. Why is SLP emitting a vector construction in BB 2 and not BB 4?
(-fno-tree-slp-vectorize disables it):

 void dummy_write_proc ()
 {
+  void (*) () * vectp.4;
+  vector(2) long unsigned int * {ref-all} vectp_myproc.3;
+  long unsigned int _7;
+  long unsigned int _8;
+  vector(2) long unsigned int _9;
+
[local count: 1073741824]:
+  _7 = VIEW_CONVERT_EXPR(dummy_write_proc);
+  _8 = VIEW_CONVERT_EXPR(dummy_write_proc);
+  _9 = {_8, _7};
   # DEBUG BEGIN_STMT
   foo ();
   goto ; [99.96%]

[local count: 429496]:
   .ABNORMAL_DISPATCHER (0);

[local count: 1073312329]:
   # DEBUG BEGIN_STMT
-  myproc.write_proc = dummy_write_proc;
-  myproc.read_proc = dummy_write_proc;
+  MEM  [(void (*) () *)&myproc] = _9;
   return;

 }

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

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

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

--- Comment #3 from Jakub Jelinek  ---
I have tried
struct Token {
  unsigned char pad[4];
  unsigned int uintdata;
  unsigned long ptrdata;
  unsigned short kind;
  unsigned char pad2[6];
  Token () : uintdata (0), ptrdata (0), kind (0) {}
  unsigned short getKind () { return kind; }
  unsigned int getLength () { return uintdata; }
  unsigned long getLiteralData () { return ptrdata; }
};
bool bar (Token &);
bool baz (unsigned long, unsigned int);
void qux ();
static inline bool
isStringLiteral (unsigned short K)
{
  return ((unsigned short) (K + 65523U) <= 1 || K == 16 || (unsigned short) (K
+ 65519U) <= 1);
}

void
foo ()
{
  Token I;
  Token Result;
  int p_count = 0;
  while (!bar (I)) {
if (I.getKind () == 21)
  ++p_count;
if (I.getKind () == 22) {
  if (p_count == 1)
break;
  --p_count;
}
Result = I;
  }
  if (Result.getKind () == 5 || Result.getKind () == 6)
{
  if (baz (Result.getLiteralData (), Result.getLength ()))
{
  qux ();
  return;
}
}
  if (!isStringLiteral (Result.getKind ()))
return;
  baz (Result.getLiteralData (), Result.getLength ());
  __builtin_abort ();
}
but while that results in very similar IL, it doesn't reproduce that.

[Bug tree-optimization/109434] [12/13 Regression] std::optional weird -Wmaybe-unitialized and behaviour with -O2

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

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

--- Comment #3 from Richard Biener  ---
So the issue is that clear_bytes_written_by doesn't handle exceptions properly
and that's thru initialize_ao_ref_for_dse.

[Bug lto/109369] LTO drops explicitly referenced symbol _pei386_runtime_relocator

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

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

--- Comment #7 from Alexander Monakov  ---
Yes, ld should claim _pei386_runtime_relocator (even if later it becomes
unneeded due to zero relocations left to fix up) to make this work properly.
That's for Binutils to fix on their side.

[Bug tree-optimization/109434] [12/13 Regression] std::optional weird -Wmaybe-unitialized and behaviour with -O2

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Hmm, we did fix such an issue already .. let me take a look.

[Bug c++/109431] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field with static constexpr array inside a template constexpr function

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/109418] -Werror=maybe-uninitialized triggered by /usr/include/c++/12.2.1/bits/random.tcc

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-04-11

--- Comment #3 from Richard Biener  ---
Waiting for a testcase, can you attach preprocessed source of the translation
unit exhibiting the issue (it's not clear from the build log which one that
is).

[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Priority|P3  |P2
   Last reconfirmed||2023-04-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Richard Biener  ---
Confirmed.  ISTR we did have another issue like this Jakub fixed recently?

[local count: 1073741824]:
+  _4 = x_7(D) > 41;
   baz (x_7(D), y_8(D));
   goto ; [99.96%]

@@ -101,9 +141,8 @@
[local count: 1073312329]:
   _1 = y_8(D) != 0;
   _2 = x_7(D) == 42;
-  _3 = _1 | _2;
   _12 = x_7(D) > 42;
-  _10 = _3 | _12;
+  _10 = _4 | _1;
   _13 = (int) _10;
   return _13;

[Bug lto/109403] Alignment of common blocks not reported correctly

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-04-11
 Status|UNCONFIRMED |NEW
 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed, not sure how well-defined "The symbol value" displayed is.  The
required info is probably also not available in the LTO symbol table entry.

[Bug other/109398] libiberty/sha1.c:234:11: warning: defining a type within 'offsetof' is a Clang extension [-Wgnu-offsetof-extensions]

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |other
   Keywords||build

--- Comment #1 from Richard Biener  ---
Looks like a possible build issue with non-GCC host compilers (but nobody
complained since 2008 when it was introduced).  Should be easy to refactor
with a local type though, just not as nicely encapsulated in 'alignof'.

[Bug c/109393] Very trivial address calculation does not fold

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |c
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-11
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
It's probably a mismatch of GENERIC/GIMPLE folding.  In this case it's
pointer_int_sum prematurely distributing the multiplication:

/* Return a tree for the sum or difference (RESULTCODE says which)
   of pointer PTROP and integer INTOP.  */

tree  
pointer_int_sum (location_t loc, enum tree_code resultcode,
 tree ptrop, tree intop, bool complain)
{ 
...
  /* If what we are about to multiply by the size of the elements
 contains a constant term, apply distributive law
 and multiply that constant term separately.
 This helps produce common subexpressions.  */

but this kind of stuff shouldn't be done by the frontends these days.

Gating this fixes the issue.  I think this piece of code should be axed
(after careful evaluation of its effect)

[Bug tree-optimization/109462] [13 Regression] Possible miscompilation of clang LocalizationChecker since r13-1938

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

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

--- Comment #2 from Jakub Jelinek  ---
Under debugger (trunk) what I see is that the block_result.intersect
(equiv_range)
in the code added by r13-1938 is only true in the VisitObjCMessageExpr function
twice, each time on the
  # Result$16_552 = PHI 
SSA_NAME, on the
 [local count: 251634481]:
if (p_count_732 == 1)
  goto ; [5.50%]
else
  goto ; [94.50%]
block (i.e. one guarded with _143 == 22 condition),
which has originally VARYING block_result, but equiv_name is strangely
_143 set by
  _143 = I.Kind;
earlier.  Obviously the range for _143 in that bb is [22, 22], that is correct,
what isn't correct is that it would be equivalent to Result$16_552.
The IL of the loop is:

   [local count: 740101405]:
  _143 = I.Kind;
  if (_143 == 21)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 251634481]:
  # RANGE [irange] int [-2147483647, +INF]
  p_count_87 = p_count_732 + 1;
  goto ; [100.00%]

   [local count: 488466924]:
  if (_143 == 22)
goto ; [70.13%]
  else
goto ; [29.87%]

   [local count: 251634481]:
  if (p_count_732 == 1)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 237794584]:
  # RANGE [irange] int [-INF, -1][1, 2147483646]
  p_count_88 = p_count_732 + -1;

   [local count: 726261510]:
  # p_count_45 = PHI 
  MEM  [(struct Token *)&Result] = MEM 
[(struct Token *)&I];
  Result$UintData_449 = MEM  [(struct Token *)&I + 4B];
  Result$PtrData_172 = MEM  [(struct Token *)&I + 8B];
  Result$16_670 = MEM  [(struct Token *)&I + 16B];
  _439 = TheLexer.D.700857.LexingRawMode;
  if (_439 != 0)
goto ; [99.96%]
  else
goto ; [0.04%]

   [local count: 313395]:
  # USE = nonlocal escaped
  # CLB = nonlocal escaped
  __assert_fail ("LexingRawMode && \"Not already in raw mode!\"",
"/usr/src/llvm-project/clang/include/clang/Lex/Lexer.h", 237, "bool
clang::Lexer::LexFromRawLexer(clang::Token&)");

   [local count: 783176091]:
  # p_count_732 = PHI 
  # Result$UintData_591 = PHI 
  # Result$PtrData_270 = PHI 
  # Result$16_552 = PHI 
  # USE = nonlocal escaped { D.1224204 D.1224214 } (escaped)
  # CLB = nonlocal escaped { D.1224204 D.1224214 } (escaped)
  clang::Lexer::Lex (&TheLexer, &I);
  # PT = nonlocal escaped null { D.1224204 D.1224214 } (escaped)
  _440 = TheLexer.BufferPtr;
  # PT = nonlocal escaped null { D.1224204 D.1224214 } (escaped)
  _441 = TheLexer.BufferEnd;
  if (_440 == _441)
goto ; [5.50%]
  else
goto ; [94.50%]

with bb 146 the loop header (before dom2), so I believe Result$16_552 is never
equivalent to _143, it is equivalent to _143 from previous loop's iteration,
not the current one.

[Bug c/109460] Build gcc for win32 failed in gcc13 master branch

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Costas Argyris  ---
As I said before, I think adding the "-o" flag to

$(COMPILER) -c $< -o $@

is a good and harmless change, but, as per your own report, it didn't solve
your issues because you still got that mysterious line:

utf8-mingw32.o: In function `WinMainCRTStartup':

which doesn't make sense to me.This makes me suspect that the problem is
something else and not the abscence of "-o".These object files have nothing
to do with such main functions that are associated with executables.So
unless you come up with gcc-specific reproduction steps for me to investigate,
you have to figure out why this object file even has a WinMainCRTStartup
function after adding the "-o" flag.

I also noticed you are using gcc 7.3 as the cross-compiler.Would it be
possible to use a more recent version, just to see if that makes a difference?

[Bug rtl-optimization/109370] Missed optimization for std::optional branchless unwrapping

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|middle-end  |rtl-optimization

--- Comment #2 from Richard Biener  ---
Note we would need to know that dereferencing 'o' is OK (not sure if RTL knows
this), and this if-conversion is certainly RTL territorry because of costing. 
On x86 I'd expect the branchy version to be faster.

[Bug lto/109369] LTO drops explicitly referenced symbol _pei386_runtime_relocator

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Alexander Monakov from comment #5)
> Indeed, sorry, __attribute__((used)) seems a much better solution for
> symbols that might be referenced implicitly, in a manner that LTO plugin
> cannot see.

OTOH if the linker(?) introduces such use then it should properly communicate
this via the resolution info.  That would hint at a binutils bug.

[Bug sanitizer/109446] Possible destination array overflow without diagnosis in memcpy

[mohamed.selim at dxc dot com via Gcc-bugs]

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

--- Comment #1 from Mohamed  ---
correction to scenario II should pass by value as follows
//void test(Bar b) // scenario II

[Bug target/109436] AArch64: suboptimal codegen in 128 bit constant stores

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-11

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Confirmed.  In terms of internals, we should probably split
128-bit GPR stores into STP patterns after RA.  That should
allow post-RA passes to remove the zero move.

[Bug c++/109471] New: Missing loop unrolling for small std::vector?

[stefano.d at posteo dot de via Gcc-bugs]

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

Bug ID: 109471
   Summary: Missing loop unrolling for small std::vector?
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefano.d at posteo dot de
  Target Milestone: ---

Hi,
I did some benchmarks where I wanted to bench a switch-case statement against a
small std::vector. In GCC 12.2 the result was as expected: The switch-case
statement was faster than the linear search in std::vector. But when I switched
to clang 13 or above, the std::vector implementation was much faster than the
switch-case statement!

You can the results here:
https://quick-bench.com/q/9DEDS7rQm0MnIFxwZt3A2iD86G0

Please switch here between GCC and clang.

Here an assembly output:

https://godbolt.org/z/j8oenP8x9

Kind regards
Stefano

[Bug c++/109470] unexpected const & behavior

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

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

--- Comment #8 from Jonathan Wakely  ---
No, "full-expression" is a formal term defined very precisely in the C++
standard. There is no opportunity for GCC to review that without failing to
conform to the C++ standard. Changing when temporary objects are destroyed
would be a massive breaking change to the C++ language that would break
assumptions made by correct code.

Just because you don't get a warning with other compilers, doesn't mean your
code is correct. The code accesses an object outside its lifetime, and so has
undefined behaviour. That is true with all compilers.

Clang gives a runtime error with -fsanitize=address e.g.
https://godbolt.org/z/dhcEhvzze

That's because the program has undefined behaviour. This is not just GCC's
interpretation of the C++ standard, it's a fact.

[Bug c++/109470] unexpected const & behavior

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
You can use -fsanitize=address to get such bugs diagnosed at runtime:
g++ -fsanitize=address -o /tmp/pr109470{,.C} -g; /tmp/pr109470
=
==2466554==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7ffe08313d80 at pc 0x00401304 bp 0x7ffe08313d20 sp 0x7ffe08313d18
READ of size 4 at 0x7ffe08313d80 thread T0
#0 0x401303 in main /tmp/pr109470.C:17
#1 0x7f5b06f7958f in __libc_start_call_main (/lib64/libc.so.6+0x2958f)
#2 0x7f5b06f79648 in __libc_start_main@GLIBC_2.2.5
(/lib64/libc.so.6+0x29648)
#3 0x4010e4 in _start (/tmp/pr109470+0x4010e4)

Address 0x7ffe08313d80 is located in stack of thread T0 at offset 64 in frame
#0 0x4011b5 in main /tmp/pr109470.C:12

  This frame has 2 object(s):
[48, 52) 'MAX' (line 14)
[64, 68) '' <== Memory access at offset 64 is inside this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /tmp/pr109470.C:17 in main
Shadow bytes around the buggy address:
  0x10004105a760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7a0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 04 f2
=>0x10004105a7b0:[f8]f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10004105a800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==2466554==ABORTING

C++ has always behaved like this and changing it would significantly penalize
all the code in the wild that uses C++ correctly.  There are some exceptions
where the lifetime is extended, but is certainly not one of them.