[Bug pending/8943] Love Match!

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug ipa/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #6 from Sam James  ---
For completeness, I should note, because some commits couldn't be built (only a
handful), git said (I've converted the commits) that it could be any of:
r12-5382-g616ca1024a79c6
r12-5383-g22c242342e38eb
r12-5381-g53c964ad996a1b
r12-5384-g3535be6c6f4409
r12-5380-g75ac95f6647367
r12-5385-g6f4ac4f81f89ca

I then verified it's r12-5383-g22c242342e38eb by going back to releases/gcc-12
and retrying a few times by applying/reverting it, but maybe there's something
useful in this list anyway.

[Bug c++/107906] linkage of template not taken into account

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Dup of bug 70413.

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

[Bug c++/70413] Class template names in anonymous namespaces are not globally unique

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

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

[Bug ipa/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #5 from Sam James  ---
(In reply to Andrew Pinski from comment #4)
> Do you know which object file inside llvm-tblgen is being miscompiled?
> You can do a binary search on object files and then provide the preprocessed
> source for that one.

Will try find out.

> 
> Also could you reproduce the miscompiling with reverting and with
> -fdump-ipa-all ? I suspect you could ...

No, interestingly, it works (no hangs) if I use -fdump-ipa-all in the flags to
build LLVM. I double checked as I was a bit surprised.

[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84925,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82029

--- Comment #3 from Andrew Pinski  ---
related to PR 84925 and PR 82029 . The first one was caused by the second one
and the second one was caused by r8-2720-gf44a8dd56f5bfb which I suspect might
have introduced this bug ...

[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|6.0 |9.0

[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|9.0 |6.0

[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|6.5 |9.0

[Bug ipa/81277] assert() in multiversioned functions causes compilation error

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64

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

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

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

[Bug tree-optimization/101634] Vectorize optimisations trigger floating point exception

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #3 from Andrew Pinski  ---


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

[Bug c++/101687] Scoped enumerators of a member enumeration shall not be referred by a class member access expression

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

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

--- Comment #2 from Andrew Pinski  ---
Hmm, MSVC also accepts this code but clang does not.

[Bug ipa/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-12-29
 Status|UNCONFIRMED |WAITING

--- Comment #4 from Andrew Pinski  ---
Do you know which object file inside llvm-tblgen is being miscompiled?
You can do a binary search on object files and then provide the preprocessed
source for that one.

Also could you reproduce the miscompiling with reverting and with
-fdump-ipa-all ? I suspect you could ...

[Bug target/108248] Some insns in the risc-v backend do not have mappings to functional units

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

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

--- Comment #4 from Jeffrey A. Law  ---
Yea, thinking about our uarch, we're going to need finer control as well. 
There's a subset that ought to execute in any ALU, but there's another subset
that are bound to a specific ALU and are potentially multi-cycle latency.

[Bug target/108248] Some insns in the risc-v backend do not have mappings to functional units

[andrew at sifive dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Waterman  ---
Yikes.  Thanks for the explanation, Jeff.

(cc Kito Cheng: at some point, we should revisit the pipeline modeling of Zb*
instructions for sifive-7.  The short version is that all Zb* instructions can
execute on the B pipe.  The A pipe supports only a subset: rev8, bext[i],
addu.w, slliu.w, sext.*, zext.*, orn, xnor, andn.  So, to do an accurate job,
we'll need finer granularity than simply describing them all as "bitmanip".)

[Bug target/108247] Missed opportunity to generate shNadd on risc-v

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

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

--- Comment #2 from Jeffrey A. Law  ---
We shouldn't use Zba just for the sake of using Zba; it needs to be profitable.
 The folks doing the analysis behind this BZ are only looking at instruction
counts -- they're not really thinking about uarch stuff or even code size,
though I think having them look at the latter in addition to dynamic counts
should be possible.

[Bug target/108247] Missed opportunity to generate shNadd on risc-v

[andrew at sifive dot com via Gcc-bugs]

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

Andrew Waterman  changed:

   What|Removed |Added

 CC||andrew at sifive dot com

--- Comment #1 from Andrew Waterman  ---
The base-ISA-only code sequence has the same instruction count but smaller code
size:

  slli a1, a1, 1
  addw a0, a1, a0
  ret

I guess this example is a proxy for a broader set of missed optimizations, some
of which are actually improved by Zba, so maybe my comment is moot.  But it
would be best not to de-optimize code size in pursuit of opportunities to use
the Zba instructions.

(It also occurs to me that the sh1add + sext.w sequence is easier to fuse
because the instructions have the same destination.  But choosing to increase
code size to avail a fusion opportunity is a uarch-specific tuning decision.)

[Bug target/108248] Some insns in the risc-v backend do not have mappings to functional units

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

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

--- Comment #2 from Jeffrey A. Law  ---
It can certainly get "unduly weird".  Basically such instructions get put at
the end of the ready queue as soon as its input dependencies are satisfied.  If
there's only a few such instructions, then the resultant schedule will be
reasonably sane.  But if all or most don't have a mapping to reservations, then
the result can be totally insane and worse than not scheduling at all.

I saw a case internally where a bunch of loads were ready to issue at the start
of a loop.  So those all go onto the ready list and get pulled off one by one
in the same order in which they were added to the ready list. As the loads
issue, dependent instructions get put on the tail of the ready list and would
issue after *all* the originally ready loads issued.  The result was the loop
had its loads bunched up at the top and the multi-cycle computation
instructions at the bottom.  We'd have been better off not scheduling it at all
as the original order interleaved the loads and computation.  This all occurred
because we didn't have any reservations defined for our chip -- so everything
was "nothing".

[Bug target/108248] Some insns in the risc-v backend do not have mappings to functional units

[andrew at sifive dot com via Gcc-bugs]

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

Andrew Waterman  changed:

   What|Removed |Added

 CC||andrew at sifive dot com

--- Comment #1 from Andrew Waterman  ---
What will the scheduler do when tuning for a pipeline model that doesn't
explicitly handle type=bitmanip?

Additional work is needed to make the sifive-7 model do the right thing, but
it's not of especially high priority if the default behavior isn't unduly
weird.

[Bug c/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #3 from Sam James  ---
Flags used to build LLVM:
export FFLAGS='-O2 -mcpu=powerpc -mtune=powerpc -pipe'
export CXXFLAGS='-O2 -mcpu=powerpc -mtune=powerpc -pipe -ggdb
-D_GLIBCXX_ASSERTIONS=1'
export LDFLAGS='-Wl,-O1 -Wl,--as-needed'
export FCFLAGS='-O2 -mcpu=powerpc -mtune=powerpc -pipe'
export CFLAGS='-O2 -mcpu=powerpc -mtune=powerpc -pipe -ggdb'

LLVM was built at llvm-project.git commit
a4e3457fb752d675c58fb14a3d8ed03fe218b6b0
for the bisect.

_GLIBCXX_ASSERTIONS seemed to make the miscompilation more likely, anecdotally,
but
the original bug reported in Gentoo didn't have this set, and I reproduced the
hang
without it. But it seems more likely to happen when it's set.

[Bug c/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #2 from Sam James  ---
LLVM build with working llvm-tblgen (with gcc revert as described above):
https://dev.gentoo.org/~sam/bugs/gcc/gcc-llvm-tblgen-ppc/bisect-maybe-broken-2022-12-28-no-hang-revert.tar.xz

LLVM build with broken llvm-tblgen (at releases/gcc-12 as described above):
https://dev.gentoo.org/~sam/bugs/gcc/gcc-llvm-tblgen-ppc/bisect-maybe-broken-2022-12-28-hangs.tar.xz

Within both tarballs, the bad binary is at bin/llvm-tblgen.

[Bug c/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb

[sam at gentoo dot org via Gcc-bugs]

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

--- Comment #1 from Sam James  ---
GCC built at releases/gcc-12 at a3fbfc1027e9edcd14bb290b5702504d80d9e8fe with a
revert of 22c242342e38ebffa6bbf7e86e7a1e4abdf0d686 which produces a working
llvm-tblgen:
```
$ gcc-12 -V
Using built-in specs.
COLLECT_GCC=gcc-12
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-unknown-linux-gnu/12/lto-wrapper
Target: powerpc-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-12.3./work/gcc-12.3./configure
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/12
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/12/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/12
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/12/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/12/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/12/include/g++-v12
--with-python-dir=/share/gcc-data/powerpc-unknown-linux-gnu/12/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 12.2.1, commit
a00a9de1ca2ed3d1740715a1a4824908350b21c0' --with-gcc-major-version-only
--disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libssp --disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --without-isl --enable-default-pie
--enable-default-ssp --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.1 20221227 (Gentoo 12.2.1, commit
a00a9de1ca2ed3d1740715a1a4824908350b21c0)
```

GCC built at releases/gcc-12 at a3fbfc1027e9edcd14bb290b5702504d80d9e8fe which
produces a broken llvm-tblgen:
```
$ gcc-12 -V
Using built-in specs.
COLLECT_GCC=gcc-12
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-unknown-linux-gnu/12/lto-wrapper
Target: powerpc-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-12.3./work/gcc-12.3./configure
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/12
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/12/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/12
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/12/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/12/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/12/include/g++-v12
--with-python-dir=/share/gcc-data/powerpc-unknown-linux-gnu/12/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 12.2.1, commit
a3fbfc1027e9edcd14bb290b5702504d80d9e8fe' --with-gcc-major-version-only
--disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libssp --disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --without-isl --enable-default-pie
--enable-default-ssp --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.1 20221227 (Gentoo 12.2.1, commit
a3fbfc1027e9edcd14bb290b5702504d80d9e8fe)
```

[Bug c/108250] New: [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb

[sam at gentoo dot org via Gcc-bugs]

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

Bug ID: 108250
   Summary: [12/13 regression] llvm-tblgen miscompiled on
powerpc-unknown-linux-gnu since
r12-5383-g22c242342e38eb
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam at gentoo dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc-unknown-linux-gnu
Target: powerpc-unknown-linux-gnu
 Build: powerpc-unknown-linux-gnu

Originally reported downstream in Gentoo at https://bugs.gentoo.org/880677. I
forwarded it to LLVM at https://github.com/llvm/llvm-project/issues/59698 too.

With GCC 12 and newer, llvm-tblgen (which is built as part of the LLVM build
process and used for part of the build) is miscompiled on
powerpc-unknown-linux-gnu. GCC 11 and older are fine.

It has two failure modes:
1. When producing a description for the PPC target in LLVM as:
```
bin/llvm-tblgen -I ~/llvm-project/llvm/lib/TargetPowerPC \
-I ~/llvm-project/llvm/include/ \
-I ~/llvm-project/llvm/lib/Target/PowerPC/ \
~/llvm-project/llvm/lib/Target/PowerPC/PPC.td \
-o /dev/null \
--gen-dag-isel \
-d /dev/null \
--time-phases \
--write-if-changed
```
it'll regularly hang (not on all runs, but if you run it 10 times, it'll hang
for several of them).
2. For X86, it'll give invalid output which later causes the LLVM compilation
to fail.

For the purposes of tracking down which GCC commit caused it, we bisected by
checking for timeouts in a loop. The result was r12-5383-g22c242342e38eb.

Reverting 22c242342e38ebffa6bbf7e86e7a1e4abdf0d686 on top of releases/gcc-12
(at a3fbfc1027e9edcd14bb290b5702504d80d9e8fe) results in a built llvm-tblgen
which doesn't hang.

Please let me know what further information you require. Access to the
environment is also available (it's purely a testing machine for this kind of
bug, no personal data on it).

[Bug middle-end/108249] cc1plus segmentation fault compiling Marlin on RPI3

[steinhelten at gmail dot com via Gcc-bugs]

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

--- Comment #3 from John Lind  ---
I'm not sure how to get that, since I am invoking it through
platformio.  What I am entering is:
/home/pi/.platformio/penv/bin/platformio run --verbose
I don't know how to get platformio to show the compiler invocation,
except I THINK that the "build_flags" is most of it.


On Wed, Dec 28, 2022 at 3:53 PM pinskia at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108249
>
> Andrew Pinski  changed:
>
>What|Removed |Added
> 
>Last reconfirmed||2022-12-28
>  Ever confirmed|0   |1
>  Status|UNCONFIRMED |WAITING
>
> --- Comment #1 from Andrew Pinski  ---
> Can you provide the full command line which is failing?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug middle-end/108249] cc1plus segmentation fault compiling Marlin on RPI3

[steinhelten at gmail dot com via Gcc-bugs]

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

--- Comment #2 from John Lind  ---
I'm not sure how to get that, since I am invoking it through platformio.
What I am entering is:
/home/pi/.platformio/penv/bin/platformio run --verbose
I don't know how to get platformio to show the compiler invocation, except
I THINK that the "build_flags" is most of it.

On Wed, Dec 28, 2022 at 3:53 PM pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108249
>
> Andrew Pinski  changed:
>
>What|Removed |Added
>
> 
>Last reconfirmed||2022-12-28
>  Ever confirmed|0   |1
>  Status|UNCONFIRMED |WAITING
>
> --- Comment #1 from Andrew Pinski  ---
> Can you provide the full command line which is failing?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug middle-end/108249] cc1plus segmentation fault compiling Marlin on RPI3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
Can you provide the full command line which is failing?

[Bug middle-end/108249] New: cc1plus segmentation fault compiling Marlin on RPI3

[steinhelten at gmail dot com via Gcc-bugs]

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

Bug ID: 108249
   Summary: cc1plus segmentation fault compiling Marlin on RPI3
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steinhelten at gmail dot com
  Target Milestone: ---

Since I am trying to compile Marlin which is very popular code, I am suspecting
that the problem is not with the code but actually in the compiler.  This is my
first attempt to submit a bug report, so I've had to guess as certain things,
like which "component" to specify for the cc1plus SIGSEGV.  Apt says I'm
running the most recent gcc.  I rebooted the system between tries.  Below is
the information I have gathered.

cc1plus: internal compiler error: Segmentation fault
0x76a3210f ???
../sysdeps/unix/sysv/linux/arm/sigrestorer.S:64
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
arm-none-eabi-g++: internal compiler error: Segmentation fault signal
terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Error: Failed to parse Marlin features. See previous error messages.

I added "-save-temps -Wall -Wextra" to the build_flags, but I can't find any
".S" files that would be pertinent as far as I can tell.
Invoking platfromio with --verbose gives, among other things, this:
build_flags: -g3 -D__MARLIN_FIRMWARE__ -DNDEBUG, -fmax-errors=5 -save-temps
-Wall -Wextra;
$ find . -name '*.i*' -exec ls -lt '{}' \+
doesn't find anything useful

pi@octopi:~/Marlin $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp
--with-float=hard --disable-werror --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) 
pi@octopi:~/Marlin $ uname -a
Linux octopi 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l
GNU/Linux
pi@octopi:~/Marlin $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/;
SUPPORT_URL="http://www.raspbian.org/RaspbianForums;
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs;
pi@octopi:~/Marlin $ cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

processor   : 1
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

processor   : 2
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

processor   : 3
model name  : ARMv7 Processor rev 4 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

Hardware: BCM2835
Revision: a22082
Serial  : fc661003
Model   : Raspberry Pi 3 Model B Rev 1.2

[Bug preprocessor/107974] compiler can't find source file in path that is longer than 255 characters

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #7 from nightstrike  ---
Someone with build system experience could modify the build of the toolchain
binaries to include a call to windres to add the manifest. This would just be
gcc itself and not what gcc produces. I guess maybe the binutils executables
would benefit also.

[Bug target/108208] Bad assembly? on large LLVM source files on powerpc-unknown-linux-gnu (Error: operand out of range)

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #2 from Segher Boessenkool  ---
Yes, agreed.  Marking this bug as invalid.

If you need a bigger code model you should use -mcmodel=large, or keep code
size under control some other way (using -O3 is a very bad idea in general;
it means "don't do tradeoffs, be overly optimistic always".  -O2 is perhaps
a bit too conservative, but -O3 definitely is too far out on the other side
of the spectrum.  Luckily there are many smaller tweak flags, and many params
you can fiddle with).

This is not a new problem at all.  The default code model we use is quite
conservative, but it is not very hard to overflow its limits.  You usually
get much better (smaller as well as faster) generated code by writing better
source code, dividing it up into translation units a bit smarter.

[Bug middle-end/101690] failure to shrink wrap simple loop with more aggressive jump threading

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

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

--- Comment #3 from Andrew Pinski  ---
Fixed in r12-4526-gd8edfadfc7a979? That removed the xfail after all.

[Bug target/108248] New: Some insns in the risc-v backend do not have mappings to functional units

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

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

Bug ID: 108248
   Summary: Some insns in the risc-v backend do not have mappings
to functional units
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
  Target Milestone: ---
Target: risc-v

If you review scheduling dumps for risc-v you will see various insns with no
reservations.  For example:

;;   11--> b  3: i  58 r184=smax(r154,r183):nothing
;;3--> b  3: i  55 r182=r180<<0x3+r160 :nothing
;;8--> b  0: i  16 r167=r193<<0x3+r193 :nothing
;;   13--> b  0: i  19 r155=r167<<0x3+r188 :nothing
;;0--> b  0: i  26 r172=r164<<0x3+r164 :nothing
;;2--> b  0: i  23 r144=r161<<0x3+r159 :nothing

It's worth noting these all seem to be coming from the bitmanip extensions. 
However, there well could be others.

It would be advisable to ensure that all insns have appropriate mappings to
functional units.

This patch from Jivan would help, but I think a thorough review to ensure
everything has a mapping would be advisable:
diff --git a/gcc/config/riscv/generic.md b/gcc/config/riscv/generic.md
index 1a209dcb997..296c4e24923 100644
--- a/gcc/config/riscv/generic.md
+++ b/gcc/config/riscv/generic.md
@@ -88,3 +88,8 @@
   (and (eq_attr "tune" "generic")
(eq_attr "type" "fsqrt"))
   "fdivsqrt*25")
+
+(define_insn_reservation "generic_smax" 1
+  (and (eq_attr "tune" "generic")
+   (eq_attr "type" "bitmanip"))
+  "alu")

[Bug testsuite/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |testsuite
  Known to work||11.3.0, 12.0
   Target Milestone|--- |11.3

[Bug c++/101747] Two-argument version of attribute malloc does not perform overload resolution

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
   |a/show_bug.cgi?id=89299 |a/show_bug.cgi?id=69020

--- Comment #4 from Andrew Pinski  ---
Sorry I mean PR 69020.

[Bug c++/101747] Two-argument version of attribute malloc does not perform overload resolution

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89299

--- Comment #3 from Andrew Pinski  ---
I suspect this is the same issue as PR 89299 really, just for cleanup attribute
rather than malloc attribute.

[Bug c++/105277] Pointer to member UB in constant expression is not checked.

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

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

--- Comment #1 from Andrew Pinski  ---
both clang and msvc also accepts this code ...

[Bug c++/108234] GCC accepts invalid program involving nontype template parameter of auto with non constexpr variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/38721

--- Comment #4 from Andrew Pinski  ---
Also:
https://github.com/llvm/llvm-project/issues/38721

[Bug c++/108234] GCC accepts invalid program involving nontype template parameter of auto with non constexpr variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/40328

--- Comment #3 from Andrew Pinski  ---
See:
https://github.com/llvm/llvm-project/issues/40328

[Bug c++/108234] GCC accepts invalid program involving nontype template parameter of auto with non constexpr variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0127r2.html

Looks like clang does not implement this paper correctly for reference types
...

Modified testcase from that paper using reference types, C++17 should reject
this while c++14 will accept it:
template  struct A;
template  int foo(A *) = delete;
void foo(void *);
constexpr int t = 1;
void bar(A *p) {
  foo(p); // ill-formed; previously well-formed
}

[Bug c++/108234] GCC accepts invalid program involving nontype template parameter of auto with non constexpr variable

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

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

--- Comment #1 from Andrew Pinski  ---
If I change func to:
template  int func(X) {  return 1; }

And then clang accepts it.
The question becomes what can be deduced as the type of V.

Here is a slightly different testcase:
```
template  struct X{};

template 
void ff(){};

template  int func(X) {  return 1; }

int i;
int main() { return func(X{}); }
```
Note GCC rejects the above testcase for C++14 but accepts it for C++17.
So I am not 100% this is invalid and clang just does not implement some rule of
C++17 correctly dealing with reference types ...

[Bug middle-end/88173] constant folding of NaN comparison depends on order of operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jonas.rahlf.basf at gmail dot 
com

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

[Bug c++/101795] (x > QNaNf) is not a constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 88173.

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

[Bug target/108247] New: Missed opportunity to generate shNadd on risc-v

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

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

Bug ID: 108247
   Summary: Missed opportunity to generate shNadd on risc-v
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
  Target Milestone: ---
Target: risc-v

int sub2(int a, long long b) {
  b = (b << 32) >> 31;
  unsigned int x = a + b;
  return x;
}


When compiled with Zba should ideally generate something like this:

  sh1add  a0, a1, a0
  sext.w  a0, a0
  ret


I suspect we need to match something like this as a define_split:

Failed to match this instruction:
(set (reg:SI 142 [ x ])
(plus:SI (subreg:SI (and:DI (ashift:DI (reg:DI 146)
(const_int 1 [0x1]))
(const_int 4294967294 [0xfffe])) 0)
(subreg:SI (reg:DI 145) 0)))


Or this:


(set (reg:DI 144 [ x ])
(sign_extend:DI (plus:SI (subreg:SI (and:DI (ashift:DI (reg:DI 146)
(const_int 1 [0x1]))
(const_int 4294967294 [0xfffe])) 0)
(subreg:SI (reg:DI 145) 0

[Bug c/66918] Disable "inline function declared but never defined" warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

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

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

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

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

Bug 100343 Summary: add -Wundefined-inline for inline function is used but not 
defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100343

   What|Removed |Added

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

[Bug c/100343] add -Wundefined-inline for inline function is used but not defined

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 66918.

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

[Bug target/108232] Bus & Segmentation error on lz4_decompress.c while make linux-raspi

[registration at filiproland dot hu via Gcc-bugs]

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

--- Comment #9 from Filip Roland  ---
Thanks Andrew I'll test tomorrow!

[Bug target/108232] Bus & Segmentation error on lz4_decompress.c while make linux-raspi

[registration at filiproland dot hu via Gcc-bugs]

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

--- Comment #8 from Filip Roland  ---
Hi!

First I tried to run make from plain terminal (Without X) in hope then will
remain more memory but it failed again.
After I 'freed' while 'make' runned at background and free memory typicaly was
over cca. 150Mi with plain terminal.
Because I didn't knewn when will it broke I runned 'free' by manually wit some
sec distinct. The result in the .txt file. The last record made after the error
report. The one before last is which was the nearest to the failure at 2-3 secs
before.
I tried to run directly the 'gcc <...>' command in background too but I cannot
'free'-d becouse it throw the fault very quickly.

After I swichted to X and ran SystemMonitor and run the 'gcc <...>' and make a
screenshot. The 'gcc <...>' runned about 10th sec, memory usage still under
100%

[Bug c++/108238] returns_nonnull attribute with auto return type fails to compile

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
   Last reconfirmed||2022-12-28
  Known to fail||4.9.0

--- Comment #1 from Andrew Pinski  ---
Confirmed, not a regression.

Some debugging:

#1  0x011e6010 in handle_returns_nonnull_attribute
(node=0x7fffd4b0, name=0x772bd9c0, no_add_attrs=0x7fffd4cf) at
/home/apinski/src/upstream-gcc/gcc/gcc/c-family/c-attribs.cc:5761
5761  error ("%qE attribute on a function not returning a pointer",
name);


5758  // Even without a prototype we still have a return type we can check.
5759  if (TREE_CODE (TREE_TYPE (*node)) != POINTER_TYPE)

(gdb) p debug_tree(*node)
 >
QI
size  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x774362a0
arg-types >>>

[Bug analyzer/108246] New: False-positive Wanalyzer-double-fclose on fclose() in loop

[roman.zilka at gmail dot com via Gcc-bugs]

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

Bug ID: 108246
   Summary: False-positive Wanalyzer-double-fclose on fclose() in
loop
   Product: gcc
   Version: 11.3.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: roman.zilka at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

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

Encountered a false-positive -Wanalyzer-double-fclose in -fanalyzer in gcc
11.3.1 and 12.2. It's accompanied by -Wanalyzer-double-free, but only in the
11.3.1.

$ cat false_fanalyzer.c 
#include 
#include 
int main() {
FILE *f = fopen("/dev/null", "w");
if (f) {
fwrite("asd", 1, 3, f);
while (fclose(f)) {
if (errno != EINTR)
break;
}
}
}

$ gcc -fanalyzer -fanalyzer-verbosity=0 false_fanalyzer.c
false_fanalyzer.c: In function ‘main’:
false_fanalyzer.c:7:16: warning: double ‘fclose’ of FILE ‘f’
[-Wanalyzer-double-fclose]
7 | while (fclose(f)) {
  |^
  ‘main’: events 1-4
|
|4 | FILE *f = fopen("/dev/null", "w");
|  |   ^~~
|  |   |
|  |   (1) opened here
|5 | if (f) {
|  |~   
|  ||
|  |(2) assuming ‘f’ is non-NULL
|6 | fwrite("asd", 1, 3, f);
|7 | while (fclose(f)) {
|  |~
|  ||
|  |(3) first ‘fclose’ here
|  |(4) second ‘fclose’ here; first ‘fclose’ was at (3)
|
false_fanalyzer.c:7:16: warning: double-‘fclose’ of ‘f’ [CWE-415]
[-Wanalyzer-double-free]
7 | while (fclose(f)) {
  |^
  ‘main’: events 1-4
|
|4 | FILE *f = fopen("/dev/null", "w");
|  |   ^~~
|  |   |
|  |   (1) allocated here
|5 | if (f) {
|  |~   
|  ||
|  |(2) assuming ‘f’ is non-NULL
|6 | fwrite("asd", 1, 3, f);
|7 | while (fclose(f)) {
|  |~
|  ||
|  |(3) first ‘fclose’ here
|  |(4) second ‘fclose’ here; first ‘fclose’ was at (3)
|

[Bug target/108232] Bus & Segmentation error on lz4_decompress.c while make linux-raspi

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

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

--- Comment #7 from Andrew Pinski  ---
Maybe you should report this to Ubuntu first since you got GCC from them.

[Bug target/108232] Bus & Segmentation error on lz4_decompress.c while make linux-raspi

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

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

--- Comment #6 from Andrew Pinski  ---
Works for me with:
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ~/upstream-gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/ubuntu/upstream-gcc/bin/gcc
COLLECT_LTO_WRAPPER=/home/ubuntu/upstream-gcc/libexec/gcc/aarch64-unknown-linux-gnu/13.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /home/ubuntu/src/upstream-gcc-aarch64/gcc/configure
--prefix=/home/ubuntu/upstream-gcc --enable-languages=c,c++,fortran,lto,objc,go
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220808 (experimental) (GCC)

[Bug c/108232] Bus & Segmentation error on lz4_decompress.c while make linux-raspi

[registration at filiproland dot hu via Gcc-bugs]

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

--- Comment #5 from Filip Roland  ---
Created attachment 54163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54163=edit
Memory Usage by 'free' while 'make' runned

[Bug c/108232] Bus & Segmentation error on lz4_decompress.c while make linux-raspi

[registration at filiproland dot hu via Gcc-bugs]

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

--- Comment #4 from Filip Roland  ---
Created attachment 54162
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54162=edit
System Monitor Scrrenshot

CPU Usage while gcc ...

[Bug c++/108245] ICE with invalid variable auto arguments and supplying an extra type

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|parser segv |ICE with invalid variable
   ||auto arguments and
   ||supplying an extra type

--- Comment #4 from Andrew Pinski  ---
Reduced further (a C++20 since C++20 expanded the use of auto to functions
rather than just lambdas but still invalid):
```
typedef int mytype;
void f(mytype auto... I) {}
```

Note without the variable argument auto, GCC rejects the code:
:2:8: error: two or more data types in declaration of 'I'
2 | void f(mytype auto I) {}
  |^~

[Bug c++/108245] parser segv

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-invalid-code
   Last reconfirmed||2022-12-28
  Known to fail||10.4.0, 11.3.0, 4.9.0,
   ||5.1.0, 6.1.0, 7.1.0, 8.1.0,
   ||9.5.0

--- Comment #3 from Andrew Pinski  ---
Confirmed.

For my reduced testcase, clang reports an error message:
:3:16: error: cannot combine with previous 'type-name' declaration
specifier
[=](mytype auto... I) { };
   ^
:3:20: error: type 'mytype' (aka 'int') of function parameter pack does
not contain any unexpanded parameter packs
[=](mytype auto... I) { };
~~~^
:3:5: warning: expression result unused [-Wunused-value]
[=](mytype auto... I) { };
^

[Bug c++/108245] parser segv

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
typedef int mytype;
void h() {
[=](mytype auto... I) { };
}

[Bug c++/108245] parser segv

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

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

--- Comment #1 from Andrew Pinski  ---
Uninclude version:
#include 

auto local_zipped_range() {
int b[10];
auto zip_it = [=](std::size_t auto... I) {
  return std::tuple(b[I], b[I])...);
};
return zip_it(std::make_index_sequence());
}

[Bug c++/108245] New: parser segv

[rscohn2 at gmail dot com via Gcc-bugs]

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

Bug ID: 108245
   Summary: parser segv
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rscohn2 at gmail dot com
  Target Milestone: ---

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

The attached program has a syntax error that causes a segv in the parser. 

Here is the compiler version:

g++-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0

It fails the same way with g++ 12.2 in compiler exporer:

https://godbolt.org/z/zKjYE44WW

And here is the error.

rscohn1@rscohn1-mobl1:test$ g++-12 -c short.ii
In file included from /usr/include/c++/12/type_traits:38,
 from /usr/include/c++/12/bits/stl_pair.h:60,
 from /usr/include/c++/12/tuple:38,
 from short.cpp:1:
/usr/include/x86_64-linux-gnu/c++/12/bits/c++config.h: In function ‘auto
local_zipped_range()’:
/usr/include/x86_64-linux-gnu/c++/12/bits/c++config.h:298:36: internal compiler
error: Segmentation fault
  298 |   typedef __SIZE_TYPE__ size_t;
  |^~~~
0xd910e3 crash_signal
../../src/gcc/toplev.cc:322
0x7fd3ecb7451f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x81ca65 tsubst_decl
../../src/gcc/cp/pt.cc:14899
0x7e6f97 cp_parser_parameter_declaration
../../src/gcc/cp/parser.cc:24868
0x7e7512 cp_parser_parameter_declaration_list
../../src/gcc/cp/parser.cc:24564
0x7e78c4 cp_parser_parameter_declaration_clause
../../src/gcc/cp/parser.cc:24491
0x7e885f cp_parser_lambda_declarator_opt
../../src/gcc/cp/parser.cc:11579
0x7cf854 cp_parser_lambda_expression
../../src/gcc/cp/parser.cc:11105
0x7d03d3 cp_parser_primary_expression
../../src/gcc/cp/parser.cc:5698
0x7d2fed cp_parser_postfix_expression
../../src/gcc/cp/parser.cc:7654
0x7bc7c6 cp_parser_binary_expression
../../src/gcc/cp/parser.cc:10035
0x7bcfce cp_parser_assignment_expression
../../src/gcc/cp/parser.cc:10339
0x7beaf9 cp_parser_constant_expression
../../src/gcc/cp/parser.cc:10642
0x7beb91 cp_parser_initializer_clause
../../src/gcc/cp/parser.cc:25223
0x7c1b7c cp_parser_initializer
../../src/gcc/cp/parser.cc:25163
0x7ef733 cp_parser_init_declarator
../../src/gcc/cp/parser.cc:22773
0x7cbb28 cp_parser_simple_declaration
../../src/gcc/cp/parser.cc:15280
0x7cd750 cp_parser_declaration_statement
../../src/gcc/cp/parser.cc:14361
0x7cdf3c cp_parser_statement
../../src/gcc/cp/parser.cc:12446
0x7cee5d cp_parser_statement_seq_opt
../../src/gcc/cp/parser.cc:12850
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.
rscohn1@rscohn1-mobl1:test$

[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Target Milestone|--- |10.5
  Known to work||7.1.0
   Last reconfirmed||2022-12-28
Summary|'__FUNCTION__' was not  |[10/11/12/13 Regression]
   |declared when used inside a |'__FUNCTION__' was not
   |generic (templated) lambda  |declared when used inside a
   |declared inside a template  |generic (templated) lambda
   |function|declared inside a template
   ||function
  Known to fail||8.1.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Note the original testcase works in GCC 8 to GCC 11 while my testcase in
comment #1 fails with those versions. 
Would be interesting to see what patch broke the original testcase and my
testcase.

[Bug c++/108242] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|'__FUNCTION__' was not  |'__FUNCTION__' was not
   |declared when used inside a |declared when used inside a
   |templated lambda declared   |generic (templated) lambda
   |inside a template function  |declared inside a template
   ||function
  Known to fail||11.3.0

--- Comment #1 from Andrew Pinski  ---
Reduced slightly more:
template
void my_fun()
{
[&](auto) {
static constexpr char const* fun_name = __func__;
struct t
{
t() { fun_name; };
} t1;
}(12);
}

int main() {
my_fun<1>();
}

[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-28
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||diagnostic,
   ||needs-bisection,
   ||rejects-valid
Summary|[13 Regression] Cannot  |[13 Regression] `pragma GCC
   |preprocess standard |diagnostic` and -E
   | header with -E  |-fdirectives-only causes
   |-fdirectives-only   |the preprocessor to become
   ||confused

--- Comment #5 from Andrew Pinski  ---
Reduced testcase that shows the issue (different warning/error message though):
```
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wctor-dtor-privacy"
#ifdef t
#endif
```
This gives:
:1:9: warning: extra tokens at end of #ifdef directive
1 | #pragma GCC diagnostic push
  | ^
Compiler returned: 0

[Bug preprocessor/108244] [13 Regression] Cannot preprocess standard header with -E -fdirectives-only

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

--- Comment #4 from Andrew Pinski  ---
The reduced header case is just:
#include 
int main() { return 0; }

[Bug preprocessor/108244] [13 Regression] Cannot preprocess standard header with -E -fdirectives-only

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

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

--- Comment #3 from Andrew Pinski  ---
Without -fdirectives-only, it works ...

[Bug preprocessor/108244] [13 Regression] Cannot preprocess standard header with -E -fdirectives-only

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||13.0
   Keywords||ice-on-valid-code
Summary|[12/13 Regression] Cannot   |[13 Regression] Cannot
   |preprocess standard |preprocess standard
   | header with -E  | header with -E
   |-fdirectives-only   |-fdirectives-only
  Known to work||12.2.0

--- Comment #2 from Andrew Pinski  ---
In file included from
/opt/compiler-explorer/gcc-trunk-20221228/include/c++/13.0.0/bits/stl_pair.h:60,
 from
/opt/compiler-explorer/gcc-trunk-20221228/include/c++/13.0.0/bits/stl_algobase.h:64,
 from
/opt/compiler-explorer/gcc-trunk-20221228/include/c++/13.0.0/algorithm:60,
 from :2:
/opt/compiler-explorer/gcc-trunk-20221228/include/c++/13.0.0/type_traits:2948:25:
error: missing binary operator before token "("
 2948 |bool _Nothrow = noexcept(_S_conv<_Tp>(_S_get())),
  | ^
/opt/compiler-explorer/gcc-trunk-20221228/include/c++/13.0.0/type_traits:3033:27:
internal compiler error: unspellable token PRAGMA_EOL
 3033 | ~__nonesuch() = delete;
  |   ^
0xd431ba c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level,
cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1])
???:0
0x238e7ba cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...)
???:0
0x2399043 cpp_spell_token(cpp_reader*, cpp_token const*, unsigned char*, bool)
???:0
0x2399e40 cpp_token_as_text(cpp_reader*, cpp_token const*)
???:0
0x239333f _cpp_parse_expr

[Bug preprocessor/108244] [12/13 Regression] Cannot preprocess standard header with -E -fdirectives-only

[gwhitneycom5 at pobox dot com via Gcc-bugs]

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

--- Comment #1 from Glen Whitney  ---
The problem is present in g++-13 but not g++-12; I wasn't sure if that meant I
should write `[12/13 Regression]` or `[13 Regression]` in the title, sorry. If
I got it wrong just let me know and I will be happy to fix.

[Bug preprocessor/108244] New: [12/13 Regression] Cannot preprocess standard header with -E -fdirectives-only

[gwhitneycom5 at pobox dot com via Gcc-bugs]

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

Bug ID: 108244
   Summary: [12/13 Regression] Cannot preprocess standard
 header with -E -fdirectives-only
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gwhitneycom5 at pobox dot com
  Target Milestone: ---

Create a file `algoproblem.cxx` containing just:

```
#include 
int main() { return 0; }
```

Now `g++-13 -E -fdirectives-only algoproblem.cxx` fails with:

```
In file included from /usr/include/c++/13/bits/stl_pair.h:60,
 from /usr/include/c++/13/bits/stl_algobase.h:64,
 from /usr/include/c++/13/algorithm:60,
 from algoproblem.cxx:1:
/usr/include/c++/13/type_traits:2948:25: error: missing binary operator before
token "("
 2948 |bool _Nothrow = noexcept(_S_conv<_Tp>(_S_get())),
  |
```

whereas `g++-12 -E -fdirectives-only algoproblem.cxx` runs to completion,
producing plausible output.

Context: I am running the build2 build system, which separates partial
preprocessing with `-E -fdirectives-only` from the main compilation. Thus,
build2 has broken when trying to switch to g++-13. I am running on an OpenSUSE
Tumbleweed linux installation, reasonably up-to-date, and `g++-13 --version`
reports:

```
g++-13 (SUSE Linux) 13.0.0 20221213 (experimental) [revision
0a43f7b1a73c8e3b9cefffe430274d0a3d6d3291]
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.
```

[Bug c++/108243] New: Missed optimization for static const std::string_view(const char*)

[erosenberger at kinetica dot com via Gcc-bugs]

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

Bug ID: 108243
   Summary: Missed optimization for static const
std::string_view(const char*)
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erosenberger at kinetica dot com
  Target Milestone: ---

Given the following code:

#include 

int main()
{
static const std::string_view foo("bar");
return foo.size();
}

With gcc 7.3.1, using "g++ -std=c++17 -O2", it treats foo as constexpr, and
compiles main to:

mov $0x3,%eax
retq

With gcc 11.3.0, also using "g++ -std=c++17 -O2", it does not treat foo as
constexpr, using runtime initialization instead (with static guard, etc.)

However, by using the string_view constructor that accepts a length:

static const std::string_view foo("bar", 3);

gcc 11.3.0 is then able to treat foo as constexpr and compiles to just a mov
and ret as 7.3.1 does.

Using Compiler Explorer it appears that gcc 9 is the first version where it
lost the optimization; every subsequent version seems to behave as 11.3.0.

---

Additional info:

gcc 11.3.0:

Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-xKiWfi/gcc-11-11.3.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) 

gcc 7.3.1:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-7/root/usr
--mandir=/opt/rh/devtoolset-7/root/usr/share/man
--infodir=/opt/rh/devtoolset-7/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-plugin --with-linker-hash-style=gnu
--enable-initfini-array --with-default-libstdcxx-abi=gcc4-compatible
--with-isl=/builddir/build/BUILD/gcc-7.3.1-20180303/obj-x86_64-redhat-linux/isl-install
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)

[Bug fortran/108131] [10/11 Regression] Incorrect bound calculation when bound intrinsic used in size expression

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11 Regression]
   |Incorrect bound calculation |Incorrect bound calculation
   |when bound intrinsic used   |when bound intrinsic used
   |in size expression  |in size expression

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13, and on 12-branch so far.  Adjusting summary.

[Bug c++/108242] New: '__FUNCTION__' was not declared when used inside a lambda declared inside a template function

[n.eugene536 at gmail dot com via Gcc-bugs]

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

Bug ID: 108242
   Summary: '__FUNCTION__' was not declared when used inside a
lambda declared inside a template function
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: n.eugene536 at gmail dot com
  Target Milestone: ---

Target: x86_64-linux-gnu
Broken since gcc 12.1; works fine with gcc <= 11.3

g++ a.cpp -std=c++14

template
void my_fun()
{
auto fun = [&](auto res) {
static constexpr char const* fun_name = __FUNCTION__;
struct
{
constexpr const char* operator()() const { return fun_name; };
} t;
t();
};

fun(12);
}


int main() {
my_fun();
}


output: Compilation error
source>:8:63: error: '__FUNCTION__' was not declared in this scope
8 | constexpr const char* operator()() const { return fun_name;
};


expected: successful compilation

Works perfectly fine with clang

[Bug fortran/108131] [10/11/12/13 Regression] Incorrect bound calculation when bound intrinsic used in size expression

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

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

commit r12-9017-gf97f032f28b3f875e5061d6b9d7ecf35897a
Author: Harald Anlauf 
Date:   Sat Dec 17 22:04:32 2022 +0100

Fortran: incorrect array bounds when bound intrinsic used in decl
[PR108131]

gcc/fortran/ChangeLog:

PR fortran/108131
* array.cc (match_array_element_spec): Avoid too early
simplification
of matched array element specs that can lead to a misinterpretation
when used as array bounds in array declarations.

gcc/testsuite/ChangeLog:

PR fortran/108131
* gfortran.dg/pr103505.f90: Adjust expected patterns.
* gfortran.dg/pr108131.f90: New test.

(cherry picked from commit 6a95f0e0a06d78d94138d4c3dd64d41591197281)

[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism

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

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

--- Comment #15 from Gaius Mulley  ---
Yes the proposed changes to the C module ctor works well and matches the
declaration in the compiler scaffold.  I'd advocate adding the attribute to
match the expected behaviour for all modules.  The startup sequence of the
ctors shouldn't matter (as mentioned elsewhere) as M2Dependent.mod self
initializes on the first call to an external procedure.

It would make sense to remove M2_link () as it was only used to pull in
dependent modules.

[Bug rtl-optimization/108241] [12/13 Regression] ICE in lra_eliminate_regs_1, at lra-eliminations.cc:658

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-28
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
Started with r13-259-g76db543db88727 which is a revision that fixed
-fvar-tracking option processing. I'm going to take a look.

[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions

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

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

--- Comment #8 from Martin Liška  ---
> @Martin: Do we have a declaration cloning code for functions somewhere?

@jamborm: PING

[Bug c++/106921] [11/12/13 Regression] -O1 and -fipa-icf -fpartial-inlining causes wrong code since r11-4987-g602c6cfc79ce4ae6

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
I've created a bit reduced test-case:

cat pr106921.c
#include 
#include 
#include 

template 
class bitset {
 private:
  using word_t = size_t;
  static constexpr size_t bits_per_word = sizeof(word_t) * 8;

 public:
  void foo(size_t n) const {
{
  if (n > Bits)
std::terminate();

  size_t i = 0;
  for (; n > bits_per_word; n -= bits_per_word, i++)
  {
__builtin_printf ("words[0]=%x, expected=%x\n", words_[i], ~word_t{});
if (words_[i] != ~word_t{0})
  __builtin_abort ();
  }
}
  }

  void fill() noexcept
  {
  for (auto& word : words_) {
  word = ~word_t{0};
  }
  }

 private:
  std::array words_{};
};

volatile int X = 0;

int main()
{
bitset<1> bitset1;
bitset1.foo(1);

bitset<66> bitset2;
bitset2.fill();

bitset2.foo(65);

  return 0;
}

So what happens? First, a split part is created and ICF merges the functions:

void bitset<1>::_ZNK6bitsetILm1EE3fooEm.part.0 (const struct bitset * const
this, size_t n)
{
  size_t i;
  const value_type & D.14201;
  const value_type & D.14200;
  long unsigned int _3;
  long unsigned int _4;

   [local count: 1073741824]:
  goto ; [100.00%]

   [local count: 0]:
  _3 = MEM  [(const value_type &)this_1(D)]._M_elems[i_2];
  __builtin_printf ("words[0]=%x, expected=%x\n", _3, 18446744073709551615);
  _4 = MEM  [(const value_type &)this_1(D)]._M_elems[i_2];
  if (_4 != 18446744073709551615)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 0]:
  n_6 = n_5 + 18446744073709551552;
  i_7 = i_2 + 1;

   [local count: 1073741824]:
  # n_5 = PHI 
  # i_2 = PHI 
  if (n_5 > 64)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 1073741824]:
  return;

}


void bitset<66>::_ZNK6bitsetILm66EE3fooEm.part.0 (const struct bitset * const
this, size_t n)
{
  size_t i;
  const value_type & D.14216;
  const value_type & D.14215;
  long unsigned int _3;
  long unsigned int _4;

   [local count: 536870913]:
  goto ; [100.00%]

   [local count: 536870913]:
  _3 = MEM  [(const value_type &)this_1(D)]._M_elems[i_2];
  __builtin_printf ("words[0]=%x, expected=%x\n", _3, 18446744073709551615);
  _4 = MEM  [(const value_type &)this_1(D)]._M_elems[i_2];
  if (_4 != 18446744073709551615)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 536870913]:
  n_6 = n_5 + 18446744073709551552;
  i_7 = i_2 + 1;

   [local count: 1073741824]:
  # n_5 = PHI 
  # i_2 = PHI 
  if (n_5 > 64)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  return;

}

I don't see there any problem, later on, the functions are inlined back and we
end up with the following in a-pr106921.c.094t.fixup_cfg3:

;; Function bitset<1>::_ZNK6bitsetILm1EE3fooEm.part.0
(_ZNK6bitsetILm1EE3fooEm.part.0, funcdef_no=539, decl_uid=14195,
cgraph_uid=120, symbol_order=148) (executed once)

void bitset<1>::_ZNK6bitsetILm1EE3fooEm.part.0 (const struct bitset * const
this, size_t n)
{
  size_t i;
  const value_type & D.14201;
  const value_type & D.14200;
  long unsigned int _3;
  long unsigned int _4;

   [local count: 1073741824]:
  goto ; [100.00%]

   [local count: 0]:
  _3 = MEM  [(const value_type &)this_1(D)]._M_elems[i_2];
  __builtin_printf ("words[0]=%x, expected=%x\n", _3, 18446744073709551615);
  _4 = MEM  [(const value_type &)this_1(D)]._M_elems[i_2];
  if (_4 != 18446744073709551615)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 0]:
  n_6 = n_5 + 18446744073709551552;
  i_7 = i_2 + 1;

   [local count: 1073741824]:
  # n_5 = PHI 
  # i_2 = PHI 
  if (n_5 > 64)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 1073741824]:
  return;

}



;; Function main (main, funcdef_no=525, decl_uid=13979, cgraph_uid=106,
symbol_order=122) (executed once)

int main ()
{
  value_type * __for_begin;
  struct bitset bitset2;
  struct bitset bitset1;

   [local count: 357878152]:
  bitset1 = {};
  bitset<1>::_ZNK6bitsetILm1EE3fooEm.part.0 (, 1);
  bitset2 = {};
  goto ; [100.00%]

   [local count: 715863673]:
  MEM[(long unsigned int &)__for_begin_6] = 18446744073709551615;
  __for_begin_7 = __for_begin_6 + 8;

   [local count: 1073741824]:
  # __for_begin_6 = PHI <[(struct array *)]._M_elems(2),
__for_begin_7(3)>
  if (  [(void *) + 16B] != __for_begin_6)
goto ; [66.67%]
  else
goto ; [33.33%]

   [local count: 357878152]:
  bitset<66>::_ZNK6bitsetILm66EE3fooEm.part.0 (, 65);
  bitset1 ={v} {CLOBBER(eol)};
  bitset2 ={v} {CLOBBER(eol)};
  return 0;

}

Which seems correct as the abort guard is based on:

  _4 = MEM  

[Bug rtl-optimization/108241] New: [12/13 Regression] ICE in lra_eliminate_regs_1, at lra-eliminations.cc:658

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 108241
   Summary: [12/13 Regression] ICE in lra_eliminate_regs_1, at
lra-eliminations.cc:658
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

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

gcc 13.0.0 20221225 snapshot (g:febb58d28bfa4b544ec7ffec2d61f46d25205ff0) ICEs
when compiling the attached testcase w/ -Os -frounding-math
-fvar-tracking-assignments -fno-dce -fno-trapping-math -fno-tree-dce
-fno-tree-dse:

% aarch64-linux-gnu-gcc-13 -Os -frounding-math -fvar-tracking-assignments
-fno-dce -fno-trapping-math -fno-tree-dce -fno-tree-dse -c ahfmksrk.c
during RTL pass: reload
ahfmksrk.c: In function 'foo':
ahfmksrk.c:60:1: internal compiler error: in lra_eliminate_regs_1, at
lra-eliminations.cc:658
   60 | }
  | ^
0x738287 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/lra-eliminations.cc:658
0xd698a2 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/lra-eliminations.cc:437
0xd694b8 lra_eliminate_regs_1(rtx_insn*, rtx_def*, machine_mode, bool, bool,
poly_int<2u, long>, bool)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/lra-eliminations.cc:601
0xd6a258 eliminate_regs_in_insn(rtx_insn*, bool, bool, poly_int<2u, long>)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/lra-eliminations.cc:1022
0xd6ab5d process_insn_for_elimination
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/lra-eliminations.cc:1332
0xd6ab5d lra_eliminate(bool, bool)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/lra-eliminations.cc:1400
0xd4e6d5 lra(_IO_FILE*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/lra.cc:2497
0xd039b9 do_reload
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/ira.cc:5941
0xd039b9 execute
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20221225/work/gcc-13-20221225/gcc/ira.cc:6127

[Bug middle-end/107284] Option properties Mask infrastructure can be extended with wide_int_bitmask

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

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

--- Comment #3 from Martin Liška  ---
Well, the ideal option would be std::bitset which would replace
host_wide_bitset.

[Bug libstdc++/108236] std::exclusive_scan with execution policy does not work in-place

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||rodgertq at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
This should be reported upstream to LLVM where the PSTL headers come from.

[Bug middle-end/107284] Option properties Mask infrastructure can be extended with wide_int_bitmask

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
So apparently it won't be so simple as cl_target_option is a GGC structure and
thus wide_int_bitmask needs to use GTY. However, I get the following errors:

/home/marxin/Programming/gcc/gcc/wide-int-bitmask.h:26: undefined type
`constexpr'
/home/marxin/Programming/gcc/gcc/wide-int-bitmask.h:26: undefined type
`constexpr'
/home/marxin/Programming/gcc/gcc/wide-int-bitmask.h:26: undefined type
`constexpr'

Just for the record, right now, there are 26 free bits available in
ix86_isa_flags2.

[Bug target/108229] [13 Regression] unprofitable STV transform since r13-4873-g0b2c1369d035e928

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

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

--- Comment #3 from Alexander Monakov  ---
Thank you! I considered this unprofitable for these reasons:

1. As you said, the code grows in size, but the speed benefit is not clear.

2. The transform converts load+add operations in a loop, and their final uses
outside of the loop. How does the costing work in this case, i.e. how are
changes for the more frequently executed instructions are weighted against
changes for the instructions that will be executed once?

3. The scalar 'add reg, mem' instruction results in one micro-fused uop that is
handled as one uop during renaming (one of narrowest point in the pipeline). It
is then issued on two execution units (for the load and for the add).

4. On AMD, there are separate fp/simd pipes, so when the code is already
simd-heavy as in this example, STV offloads instructions from the integer pipes
to the possibly already-busy simd/fp pipes.

That said, the transformed portion is small relative to the inner loop of the
example, so benchmarking yesterday's trunk with/without -mno-stv on Zen 2, I
get:

27.26 bytes/cycle, 3.07 instruction/cycle

vs.

26.01 bytes/cycle, 2.97 instruction/cycle

So it's not the end of the world for this particular example, but I wanted to
raise the issue in case there's a costing problem in STV that needs correcting.

[Bug tree-optimization/107467] [12/13 Regression] Miscompilation involing -Os , -flto and -fno-strict-aliasing

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
   Keywords|needs-bisection |
 Status|ASSIGNED|NEW

--- Comment #6 from Martin Liška  ---
Running that under valgrind I see it started with r12-656-ga564da506f52be66:

==13643== Conditional jump or move depends on uninitialised value(s)
==13643==at 0x401148: bool compare_pairs(pair
const&, pair const&) (pr107467-2.C:12)
==13643==by 0x401176: Combined::clashy() [clone .isra.0]
(pr107467-2.C:23)
==13643==by 0x4011B2: other_func() (pr107467-2.C:40)
==13643==by 0x4011ED: main (pr107467-2.C:48)

So I guess it might be something in between DSE and aliasing info investigated
by IPA modref.

@Honza: Can you take a look?

[Bug target/64384] mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI

[alvinhochun at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Alvin Wong  ---
P.S. related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52792

[Bug target/64384] mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI

[alvinhochun at gmail dot com via Gcc-bugs]

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

Alvin Wong  changed:

   What|Removed |Added

 CC||alvinhochun at gmail dot com

--- Comment #8 from Alvin Wong  ---
According to https://devblogs.microsoft.com/oldnewthing/20220113-00/?p=106152,
Microsoft acknowledged that the behaviour is different between free function
and C++ member functions, and that it does cause breakage of the COM ABI
between C and C++. What they have done is to update the MIDL compiler to
generate C bindings compatible with the C++ ABI. (I filed
https://bugs.winehq.org/show_bug.cgi?id=54226 for implementing the same
function in widl.)

In this sense, the current behaviour of gcc and g++ regarding free functions
should be correct and does not need fixing. Only the ABI for C++ class member
functions are wrong.

[Bug target/108229] [13 Regression] unprofitable STV transform since r13-4873-g0b2c1369d035e928

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #2 from Roger Sayle  ---
Created attachment 54159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54159=edit
compute_convert_gain patch

I believe the attached patch should improve things, by tweaking the gains/costs
used by the STV pass.  Previously, GCC wasn't taking into account the
conversion of memory references in operands of PLUS.  In terms of u-ops/memory
loads, the before and after in the bugzilla PR are pretty much equivalent, so
the effect is subtle and probably depends on target microarchitecture.  If
folks could benchmark this change, and post the results I'd very much
appreciate it.  It would also be good to understand why/where this change
was/is considered "unprofitable".  The one thing I can guarantee is that with
this proposed patch, GCC no longer increases function size with -Os [a tangible
measure of unprofitable].

[Bug c++/107597] LTO causes static inline variables to get a non-uniqued global symbol

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
> So this is kind of feature.   How the ODR violations are detected?
> I wonder if keeping weak flag disturbs something.

ASAN emits so-called ODR indicators for all global symbols that survive the
following check: asan_needs_odr_indicator_p (tree decl)
in asan.cc:3216

And that's we see 2 of them:

marxin@marxinbox:~/Programming/testcases/PR107597> nm libTest1.so | grep odr
40c0 B __odr_asan._ZN12NonTemplated1xE
marxin@marxinbox:~/Programming/testcases/PR107597> nm libTest2.so | grep odr
40c0 B __odr_asan._ZN12NonTemplated1xE

which eventually ends up with the run-time error.

[Bug c++/107597] LTO causes static inline variables to get a non-uniqued global symbol

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

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

--- Comment #5 from Martin Liška  ---
> 
> So this is kind of feature.   How the ODR violations are detected?

ASAN emits 

> I wonder if keeping weak flag disturbs something.

[Bug target/108240] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.0
   Last reconfirmed||2022-12-28

[Bug ipa/107944] [11/12/13 Regression] ICE in cgraph_node::get_untransformed_body since r13-48-g27ee75dbe81bb7

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Liška  ---
Patch candidate:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607623.html

[Bug middle-end/107966] [10/11/12/13 Regression] option property Var(var) documentation seems cut off

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Liška  ---
Patch candidate:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609223.html

[Bug target/108240] New: ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

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

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

Bug ID: 108240
   Summary: ICE in emit_library_call_value_1 at gcc/calls.cc:4181
since r13-4894-gacc727cf02a144
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: linkw at gcc dot gnu.org
  Target Milestone: ---

Since the revision, I see:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/minloc_string_1.f90
-mmodulo -mcpu=401
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/minloc_string_1.f90:21:16:

   21 |   a = int(r*100)
  |^
internal compiler error: Segmentation fault
0x11c81f8 crash_signal
/home/marxin/Programming/gcc2/gcc/toplev.cc:314
0x778d18df ???
   
/usr/src/debug/glibc-2.36/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xe00886 aggregate_value_p(tree_node const*, tree_node const*)
/home/marxin/Programming/gcc2/gcc/function.cc:2056
0xc442d3 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
/home/marxin/Programming/gcc2/gcc/calls.cc:4181
0xda7819 emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, rtx_def*, machine_mode)
/home/marxin/Programming/gcc2/gcc/rtl.h:4399
0xda7819 convert_mode_scalar
/home/marxin/Programming/gcc2/gcc/expr.cc:529
0xda8c30 convert_modes(machine_mode, machine_mode, rtx_def*, int)
/home/marxin/Programming/gcc2/gcc/expr.cc:931
0x107f7ab expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
/home/marxin/Programming/gcc2/gcc/optabs.cc:1671
0xd8c0a7 expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
/home/marxin/Programming/gcc2/gcc/expmed.cc:3600
0xc5b080 expand_gimple_stmt_1
/home/marxin/Programming/gcc2/gcc/cfgexpand.cc:3983
0xc5b080 expand_gimple_stmt
/home/marxin/Programming/gcc2/gcc/cfgexpand.cc:4044
0xc605be expand_gimple_basic_block
/home/marxin/Programming/gcc2/gcc/cfgexpand.cc:6096
0xc61ec6 execute
/home/marxin/Programming/gcc2/gcc/cfgexpand.cc:6822
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.

while the code was rejected before the revision with:
f951: Error: ‘-m64’ requires a PowerPC64 cpu

[Bug middle-end/107976] ICE: SIGSEGV (stack overflow) in emit_case_dispatch_table (stmt.cc:783) with large --param=jump-table-max-growth-ratio-for-speed

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c/107993] ICE: tree check: expected string_cst, have integer_cst in get_target_clone_attr_len, at tree.cc:14872

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug middle-end/108237] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 at -O since r13-1085-g90467f0ad649d081

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.0
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
Summary|[13 Regression] ICE: in |[13 Regression] ICE: in
   |gimple_expand_vec_cond_expr |gimple_expand_vec_cond_expr
   |, at gimple-isel.cc:281 at  |, at gimple-isel.cc:281 at
   |-O  |-O since
   ||r13-1085-g90467f0ad649d081
   Last reconfirmed||2022-12-28

--- Comment #1 from Martin Liška  ---
Started with r13-1085-g90467f0ad649d081

[Bug libstdc++/108236] std::exclusive_scan with execution policy does not work in-place

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-28

[Bug c/107993] ICE: tree check: expected string_cst, have integer_cst in get_target_clone_attr_len, at tree.cc:14872

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Liška  ---
Patch candidate:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609219.html

[Bug tree-optimization/108137] [12 Regression] ICE: segfault during GIMPLE pass: warn-printf since r12-523-g2254b3233b5bfa69

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[12/13 Regression] ICE: |[12 Regression] ICE:
   |segfault during GIMPLE  |segfault during GIMPLE
   |pass: warn-printf since |pass: warn-printf since
   |r12-523-g2254b3233b5bfa69   |r12-523-g2254b3233b5bfa69
  Known to work||13.0

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

[Bug tree-optimization/108137] [12/13 Regression] ICE: segfault during GIMPLE pass: warn-printf since r12-523-g2254b3233b5bfa69

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

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

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

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

commit r13-4911-gee6f262b87fef590729e96e999f1c3b207c251c0
Author: Martin Liska 
Date:   Fri Dec 23 15:27:32 2022 +0100

strlen: do not use cond_expr for boundaries

PR tree-optimization/108137

gcc/ChangeLog:

* tree-ssa-strlen.cc (get_range_strlen_phi): Reject anything
different from INTEGER_CST.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr108137.c: New test.

[Bug c++/106435] constructor of thread_local static member is not called

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

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

--- Comment #11 from Iain Sandoe  ---
posted here
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608096.html