[Bug c++/120013] SIGSEGV ICE with modules related to instantiation of templates across partition units

[miuna.oshino at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Amber Ehrlich  ---
Ehh he's not sure so I'll do it anyways. Removing the other 2 cases from this
post

[Bug ipa/120006] [15 Regression] wrong code with -O2 -fipa-pta

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

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

--- Comment #4 from Sam James  ---
I can have a look at reducing if nobody else can, just it may be a few days.
But 
are you sure fsck.c is actually the miscompiled file (verified that)?

> 
> I diffed the new preprocessed file with the old one and they were the same,
> so I won't reupload it.

(It would be -- the object file is what would differ.)

[Bug c++/120015] internal compiler error: in unify, at cp/pt.cc:25969

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=117035,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101670
   Last reconfirmed||2025-04-30

--- Comment #1 from Andrew Pinski  ---
Confirmed. related to PR 117035 and PR 101670.

[Bug rust/120018] internal compiler error: in redirect_to_unreachable, at ipa-fnsummary.cc:258 for 32-bits

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||dkm at gcc dot gnu.org,
   ||gcc-rust at gcc dot gnu.org,
   ||pierre-emmanuel.patry@embec
   ||osm.com
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-04-30
  Component|ipa |rust

--- Comment #1 from Andrew Pinski  ---
>Or maybe the rust frontend is doing something incorrect with 
>__builtin_unreachable?

yes the rust front-end needs a fix; I think there is no cold attribute
existing. See r15-7378-g0006c07b7ac659 (fix for go) and
r15-7476-g4abac2ffdb071c (fix for the "LTO" front-end)

[Bug rust/120018] internal compiler error: in redirect_to_unreachable, at ipa-fnsummary.cc:258 for 32-bits

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Oh r15-7476-g4abac2ffdb071c added the check too.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #31 from LIU Hao  ---
(In reply to Gabriel Ivăncescu from comment #30)
> Why would it not be safe? For MinGW specifically, what's not safe about it?
> The entire Windows stack assumes only 4-byte alignment for i386, because
> that's what MSVC provides. So interoperability with MSVC code (including
> Windows DLLs or 3rd party libraries) means that anything that requires
> stricter alignment *MUST* realign the stack, or else it would break.
> 
> Therefore it should be completely safe for Windows i386 target.

There's code that expects `__attribute__((__force_align_arg_pointer__))` to
align the stack to 16-byte boundaries.

https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682180.html

[Bug c++/120017] New: Nested diagnostics could be slightly improved for concepts-related diagnostics

[ensadc at mailnesia dot com via Gcc-bugs]

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

Bug ID: 120017
   Summary: Nested diagnostics could be slightly improved for
concepts-related diagnostics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

This issue is specific to the new `experimental-nesting` option
(`-fdiagnostics-set-output=text:experimental-nesting=yes`).


https://godbolt.org/z/Wc1fqzoan

template
struct A {};

template
using B = A::B;

template
concept C = false;

template
concept D = requires(T t) {
typename B;
requires C;
};

static_assert(D);


:16:15: error: static assertion failed
:16:15: note: constraints not satisfied
  • (level 1):required by the constraints of 'template concept D'
  • (level 1):in requirements with 'T t' [with T = int]
  • (level 1):the required type 'B' is invalid, because
  • (level 1):In substitution of 'template using B = typename A::B
[with T = int]':
  • (level 1):required from here
  • (level 1):error: no type named 'B' in 'struct A'
  • (level 1):nested requirement 'C' is not satisfied, because
  • (level 1):required for the satisfaction of 'C' [with T = int]
  • (level 1):the expression 'false' evaluated to 'false'


I'm using `experimental-nesting-show-locations=no`,
`experimental-nesting-show-levels=yes` and `-fno-diagnostics-show-caret` to
make it clearer to see the issue, and `-fconcepts-diagnostics-depth=3` to make
GCC not truncate the concepts-related diagnostics. So the full command-line is:

g++ -std=c++20
-fdiagnostics-set-output=text:experimental-nesting=yes,experimental-nesting-show-locations=no,experimental-nesting-show-levels=yes
-fno-diagnostics-show-caret -fconcepts-diagnostics-depth=3 example.cpp

I expect the messages after "because" to be more nested than the ones that end
with "because". That is, I expect the nesting levels to be:

```
:16:15: error: static assertion failed
:16:15: note: constraints not satisfied
  • (level 1):required by the constraints of 'template concept D'
  • (level 1):in requirements with 'T t' [with T = int]
  • (level 1):the required type 'B' is invalid, because
• (level 2):In substitution of 'template using B = typename A::B
[with T = int]':
• (level 2):required from here
• (level 2):error: no type named 'B' in 'struct A'
  • (level 1):nested requirement 'C' is not satisfied, because
• (level 2):required for the satisfaction of 'C' [with T = int]
• (level 2):the expression 'false' evaluated to 'false'
```

By the way, the nested messages are already a huge improvement to the old, flat
structure. I really appreciate it.

[Bug c++/120015] New: internal compiler error: in unify, at cp/pt.cc:25969

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 120015
   Summary: internal compiler error: in unify, at cp/pt.cc:25969
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

Invalid code uses tag without a second parameter.

template 
struct tag {};

template 
bool foo(tag);

tag x;
auto y = foo(x);

Works for valid code:

template 
bool foo(tag);

Live: https://godbolt.org/z/YKorqs95P [April 29th, 2025]

[Bug c++/120014] New: SIGSEGV ICE with modules related to instantiation of templates across partition units (case 2)

[miuna.oshino at gmail dot com via Gcc-bugs]

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

Bug ID: 120014
   Summary: SIGSEGV ICE with modules related to instantiation of
templates across partition units (case 2)
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miuna.oshino at gmail dot com
  Target Milestone: ---

Created attachment 61245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61245&action=edit
Crash 2 project files + preprocessed source

Possible duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013,
though this is a different error message.

> In all cases g++ crashes because of including certain std headers in `hewwo` 
> in the partition chain `hewwo -> uwu -> owo`.
> Many headers cause this, but we will use  as a scapegoat because it 
> is my sworn enemy
> 
> CRASH 2: `export import :uwu;` 
> - `hewwo`: Variable with 
> - `uwu`:  Alias to DIFFERENT array **(no chrono)**
> - `owo`:  Variable of DIFFERENT array **(no chrono)**
> - Happens when `owo` does not have .
> - Including  in `uwu` but NOT in `owo` changes the crash to `export 
> import :owo;` (passes through uwu without an issue)
> - Removing the instantiation of a different array symbol in `uwu` changes the 
> crash to `export import :owo;`.   (passes through uwu without an issue)
> - Including  in all 3 fixes it.
> - `export` or not doesn't change anything at all, on any of the 3 symbols
> - Maybe same as crash 1 but different context for diagnostics?

FAILED: CMakeFiles/meow.dir/meow.ixx.o CMakeFiles/meow.dir/meow.gcm
/usr/local/bin/g++   -std=c++20 -freport-bug -Wall -Wextra -pedantic -MD -MT
CMakeFiles/meow.dir/meow.ixx.o -MF CMakeFiles/meow.dir/meow.ixx.o.d
-fmodules-ts -fmodule-mapper=CMakeFiles/meow.dir/meow.ixx.o.modmap -MD
-fdeps-format=p1689r5 -x c++ -o CMakeFiles/meow.dir/meow.ixx.o -c
/home/miuna/dev/crash-2/meow.ixx
/home/miuna/dev/crash-2/meow.ixx:6:20: internal compiler error: Segmentation
fault
6 | export import :uwu;
  |^
0x22cc84f internal_error(char const*, ...)
/home/miuna/dev/gcc/gcc/diagnostic-global-context.cc:517
0xfe115f crash_signal
/home/miuna/dev/gcc/gcc/toplev.cc:322
0x7faed2dd932f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x78419a install_entity
/home/miuna/dev/gcc/gcc/cp/module.cc:8109
0x78419a decl_value
/home/miuna/dev/gcc/gcc/cp/module.cc:8657
0x8e8a94 tree_node
/home/miuna/dev/gcc/gcc/cp/module.cc:10062
0x8ed09c module_state::read_cluster(unsigned int)
/home/miuna/dev/gcc/gcc/cp/module.cc:16673
0x8edb67 module_state::load_section(unsigned int, binding_slot*)
/home/miuna/dev/gcc/gcc/cp/module.cc:20217
0x8f19cb module_state::read_language(bool)
/home/miuna/dev/gcc/gcc/cp/module.cc:20146
0x8f1af8 module_state::read_language(bool)
/home/miuna/dev/gcc/gcc/cp/module.cc:21206
0x8f1af8 direct_import
/home/miuna/dev/gcc/gcc/cp/module.cc:21208
0x971a1e cp_parser_translation_unit
/home/miuna/dev/gcc/gcc/cp/parser.cc:5434
0x971a1e c_parse_file()
/home/miuna/dev/gcc/gcc/cp/parser.cc:53961
0xa7e561 c_common_parse_file()
/home/miuna/dev/gcc/gcc/c-family/c-opts.cc:1379
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/cczVGCYu.out file, please attach this to
your bugreport.
ninja: build stopped: subcommand failed.

[Bug ipa/120006] [15 Regression] wrong code with -O2 -fipa-pta

[anhollander516 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Avraham Hollander  ---
(In reply to Sam James from comment #4)
> I can have a look at reducing if nobody else can, just it may be a few days.
> But 
> are you sure fsck.c is actually the miscompiled file (verified that)?
> 
> > 
> > I diffed the new preprocessed file with the old one and they were the same,
> > so I won't reupload it.
> 
> (It would be -- the object file is what would differ.)

I was rushing out the door this morning, but now I'm able to take a closer look
at build.log.

Here's the command line for creating the fsck binary:
/bin/sh ./libtool  --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc -fsigned-char
-fno-common -Wall -Wextra -Waddress-of-packed-member -Wdiscarded-qualifiers
-Wformat-security -Wimplicit-function-declaration -Wmissing-declarations
-Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs
-Wno-missing-field-initializers -Wold-style-definition -Wpointer-arith
-Wredundant-decls -Wsign-compare -Wstrict-prototypes -Wtype-limits
-Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable
-Wunused-parameter -Wunused-result -Wunused-variable -Wvla -Walloca
-Werror=sequence-point -I./libmount/src -I./libblkid/src -O2 -fipa-pta
-save-temps -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -o fsck
disk-utils/fsck-fsck.o lib/fsck-monotonic.o  libmount.la libblkid.la
libcommon.la

So the fsck binary is made from disk-utils/fsck-fsck.o and
lib/fsck-monotonic.o.

disk-utils/fsck-fsck.o is compiled from disk-utils/fsck.c:
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
-I/var/tmp/portage/sys-apps/util-linux-2.41/work/util-linux-2.41  -include
config.h
-I/var/tmp/portage/sys-apps/util-linux-2.41/work/util-linux-2.41/include
-DLOCALEDIR=\"/usr/share/locale\" -D_PATH_RUNSTATEDIR=\"/run\"
-D_PATH_LOCALSTATEDIR=\"/var\" -D_PATH_SYSCONFSTATICDIR=\"/usr/lib\"   
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fsigned-char
-fno-common -Wall -Wextra -Waddress-of-packed-member -Wdiscarded-qualifiers
-Wformat-security -Wimplicit-function-declaration -Wmissing-declarations
-Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs
-Wno-missing-field-initializers -Wold-style-definition -Wpointer-arith
-Wredundant-decls -Wsign-compare -Wstrict-prototypes -Wtype-limits
-Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable
-Wunused-parameter -Wunused-result -Wunused-variable -Wvla -Walloca
-Werror=sequence-point -I./libmount/src -I./libblkid/src -O2 -fipa-pta
-save-temps -c -o disk-utils/fsck-fsck.o `test -f 'disk-utils/fsck.c' || echo
'/var/tmp/portage/sys-apps/util-linux-2.41/work/util-linux-2.41/'`disk-utils/fsck.c

lib/fsck-monotonic.o is compiled from lib/monotonic.c:
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
-I/var/tmp/portage/sys-apps/util-linux-2.41/work/util-linux-2.41  -include
config.h
-I/var/tmp/portage/sys-apps/util-linux-2.41/work/util-linux-2.41/include
-DLOCALEDIR=\"/usr/share/locale\" -D_PATH_RUNSTATEDIR=\"/run\"
-D_PATH_LOCALSTATEDIR=\"/var\" -D_PATH_SYSCONFSTATICDIR=\"/usr/lib\"   
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fsigned-char
-fno-common -Wall -Wextra -Waddress-of-packed-member -Wdiscarded-qualifiers
-Wformat-security -Wimplicit-function-declaration -Wmissing-declarations
-Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs
-Wno-missing-field-initializers -Wold-style-definition -Wpointer-arith
-Wredundant-decls -Wsign-compare -Wstrict-prototypes -Wtype-limits
-Wuninitialized -Wunused-but-set-parameter -Wunused-but-set-variable
-Wunused-parameter -Wunused-result -Wunused-variable -Wvla -Walloca
-Werror=sequence-point -I./libmount/src -I./libblkid/src -O2 -fipa-pta
-save-temps -c -o lib/fsck-monotonic.o `test -f 'lib/monotonic.c' || echo
'/var/tmp/portage/sys-apps/util-linux-2.41/work/util-linux-2.41/'`lib/monotonic.c

So it could be code from either of those files. How would you narrow that down
further?

[Bug ipa/120006] [15/16 Regression] wrong code with -O2 -fipa-pta

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

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

--- Comment #7 from Sam James  ---
Created attachment 61247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61247&action=edit
fsck.i.xz

Reduced (but could do with more) testcase attached.

$ gcc fsck.c -o fsck -save-temps -O2 -fsigned-char && ./fsck -V /boot -a # ok
$ gcc fsck.c -o fsck -save-temps -O2 -fsigned-char -fipa-pta && ./fsck -V /boot
-a # abort

[Bug ipa/120006] [15/16 Regression] wrong code with -O2 -fipa-pta

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

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

--- Comment #9 from Sam James  ---
I need to do other things for tonight so won't be reducing it further for now.
Feel free to take over.

[Bug ipa/120006] [15/16 Regression] wrong code with -O2 -fipa-pta

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

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

--- Comment #8 from Sam James  ---
Created attachment 61248
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61248&action=edit
fsck.c

[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86

[kostikbel at ukr dot net via Gcc-bugs]

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

--- Comment #11 from Konstantin Belousov  ---
Also the following regression was introduced in 15:

--- gcc/ada/init.c~ 2025-04-25 11:18:00.0 +0300
+++ gcc/ada/init.c  2025-04-26 08:07:51.804119000 +0300
@@ -1686,8 +1686,8 @@
 #include 
 #include 

-#ifdef __CHERI__
 static void
+#ifdef __CHERI__
 __gnat_error_handler (int sig,
  siginfo_t *si,
  void *ucontext ATTRIBUTE_UNUSED)

[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86

[kostikbel at ukr dot net via Gcc-bugs]

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

Konstantin Belousov  changed:

   What|Removed |Added

 CC||kostikbel at ukr dot net

--- Comment #10 from Konstantin Belousov  ---
(In reply to Gerald Pfeifer from comment #6)
> FreeBSD i386 is on it's way out: FreeBSD 14 is the last series supporting
> it; FreeBSD 15 is dropping support for it.
> 
> Can we disable libgnat (or GNAT) support during configure time?
32bit userspace is still there and will be.  I do not see a reason to break
multilib.

[Bug c++/120013] SIGSEGV ICE with modules related to instantiation of templates across partition units

[miuna.oshino at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Amber Ehrlich  ---
Ahh I can't edit, well, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120014 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120016 are crash 2 and 3
respectively

[Bug target/120011] [15/16 Regression] Impossible asm constraints in 32 bit libgcc when compiling with -march=x86-64-v4 -Os since r15-9176-g564e4e08190229

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

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

Sam James  changed:

   What|Removed |Added

Summary|[15/16 Regression]  |[15/16 Regression]
   |Impossible asm constraints  |Impossible asm constraints
   |in 32 bit libgcc when   |in 32 bit libgcc when
   |compiling with  |compiling with
   |-march=x86-64-v4 -Os|-march=x86-64-v4 -Os since
   ||r15-9176-g564e4e08190229
   Keywords|needs-bisection |

--- Comment #12 from Sam James  ---
r15-9176-g564e4e08190229

[Bug ipa/120006] [15 Regression] wrong code with -O2 -fipa-pta

[anhollander516 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Avraham Hollander  ---
(In reply to Andrew Pinski from comment #2)
> Can you try the backporting the commit in PR 119973 and seeing if that fixes
> this one too?  If so please close this as a dup of bug 119973.

It did not fix the problem, sadly.

I diffed the new preprocessed file with the old one and they were the same, so
I won't reupload it.

[Bug target/117312] RFE: x86 (and perhaps others): inline assembly: "red-zone" clobber

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug libstdc++/109162] C++23 improvements to std::format

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

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

--- Comment #27 from GCC Commits  ---
The master branch has been updated by Tomasz Kaminski :

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

commit r16-293-g2ca5725e104d432317a44ad45183a4f555da3b82
Author: Tomasz KamiÅski 
Date:   Fri Apr 25 20:10:52 2025 +0200

libstdc++: Fix _Padding_sink in case when predicted width is between
padwidth and maxwidth [PR109162]

The _Padding_sink was behaving incorrectly, when the predicted width (based
on
code units count) was higher than _M_maxwidth, but lower than _M_padwidth.
In this case _M_update() returned without calling _M_force_update() and
computing
field width for Unicode encoding, because _M_buffering() returned 'true'.
As a consequence we switched to _M_ignoring() mode, while storing a
sequence
with more code units but smaller field width than _M_maxwidth.

We now call _M_force_update() if predicted width is greater or equal to
either
_M_padwidth or _M_maxwidth.

This happened for existing test case on 32bit architecture.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/std/format (_Padding_sink::_M_update): Fixed condition
for
calling _M_force_update.
* testsuite/std/format/debug.cc: Add test that reproduces this
issue
on 64bit architecture.
* testsuite/std/format/ranges/sequence.cc: Another edge value test.

[Bug fortran/119986] Complex array part references are being passed incorrectly to a procedure

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

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

--- Comment #4 from Neil Carlson  ---
(In reply to kargls from comment #3)
> Also note, that the above generates the expected temporary arrays.

A tangential question: Why is this expected? I would have naively thought that
a dope
vector with a stride of 2 (assuming the real and imaginary parts are
interleaved)
could have been created and passed without copying the actual array elements.
Or does
"creating array temporary" not necessarily mean data copying is occurring?

[Bug target/119547] RISC-V: VSETVL mistakenly modified other data

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

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

--- Comment #19 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Kito Cheng :

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

commit r14-11700-gae6ce4cd33d00b8acc9503b0d4883fa92c1a696d
Author: Robin Dapp 
Date:   Fri Apr 4 17:06:44 2025 +0200

RISC-V: Do not lift up vsetvl into non-transparent blocks [PR119547].

When lifting up a vsetvl into a block we currently don't consider the
block's transparency with respect to the vsetvl as in other parts of the
pass.  This patch does not perform the lift when transparency is not
guaranteed.

This condition is more restrictive than necessary as we can still
perform a vsetvl lift if the conflicting register is only every used
in vsetvls and no regular insns but given how late we are in the GCC 15
cycle it seems better to defer this.  Therefore
gcc.target/riscv/rvv/vsetvl/avl_single-68.c is XFAILed for now.

This issue was found in OpenCV where it manifests as a runtime error.
Zhijin Zeng debugged PR119547 and provided an initial patch.

Reported-By: æ¾æ²»é 

PR target/119547

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc
(pre_vsetvl::earliest_fuse_vsetvl_info):
Do not perform lift if block is not transparent.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/vsetvl/avl_single-68.c: xfail.
* g++.target/riscv/rvv/autovec/pr119547.C: New test.
* g++.target/riscv/rvv/autovec/pr119547-2.C: New test.
* gcc.target/riscv/rvv/vsetvl/vlmax_conflict-3.c: Adjust.
* gcc.target/riscv/rvv/vsetvl/vlmax_conflict-12.c: Adjust.
* gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-10.c: Adjust.

(cherry picked from commit 517f7e3f02b4c945d2b4bdabb490961cf986391e)

[Bug target/119533] RISC-V: libgo build failures (ICE) with Vector enabled

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Kito Cheng :

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

commit r14-11701-ge363940e1cef7f6face970414ffaa565daf413bd
Author: Vineet Gupta 
Date:   Tue Apr 15 09:29:08 2025 -0700

RISC-V: vsetvl: elide abnormal edges from LCM computations [PR119533]

vsetvl phase4 uses LCM guided info to insert VSETVL insns, including a
straggler loop for "mising vsetvls" on certain edges. Currently it
asserts on encountering EDGE_ABNORMAL.

When enabling go frontend with V enabled, libgo build hits the assert.

The solution is to prevent abnormal edges from getting into LCM at all
(my prior attempt at this just ignored them after LCM which is not
right). Existing invalid_opt_bb_p () current does this for BB predecessors
but not for successors which is what the patch adds.

Crucially, the ICE/fix also depends on avoiding vsetvl hoisting past
non-transparent blocks: That is taken care of by Robin's patch
"RISC-V: Do not lift up vsetvl into non-transparent blocks [PR119547]"
for a different yet related issue.

Reported-by: Heinrich Schuchardt 
Signed-off-by: Vineet Gupta 

PR target/119533

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (invalid_opt_bb_p): Check for
EDGE_ABNOMAL.
(pre_vsetvl::compute_lcm_local_properties): Initialize kill
bitmap.
Debug dump skipped edge.

gcc/testsuite/ChangeLog:

* go.dg/pr119533-riscv.go: New test.
* go.dg/pr119533-riscv-2.go: New test.

(cherry picked from commit edb4867412895100b3addc525bc0dba0ea90c7f9)

[Bug ipa/120006] [15/16 Regression] wrong code with -O2 -fipa-pta

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

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

--- Comment #11 from Sam James  ---
Created attachment 61249
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61249&action=edit
small.c

This cvise-mangled one (tidied up a fair bit after) seems to do it, but it's
weird, e.g. swapping g/h makes it fail with GCC 10..14 at least w/ -fipa-pta.

I think this extra reduction may be a different bug? We always have initialised
b here because f = 1, so...?

[Bug fortran/119986] Complex array part references are being passed incorrectly to a procedure

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #5 from kargls at comcast dot net ---
On 4/29/25 17:01, neil.n.carlson at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
> 
> --- Comment #4 from Neil Carlson  ---
> (In reply to kargls from comment #3)
>> Also note, that the above generates the expected temporary arrays.
> 
> A tangential question: Why is this expected? I would have naively thought that
> a dope
> vector with a stride of 2 (assuming the real and imaginary parts are
> interleaved)
> could have been created and passed without copying the actual array elements.
> Or does
> "creating array temporary" not necessarily mean data copying is occurring?

Well, it's expected by me. :)

gfortran has to mangle your code into something that the middle-end
can digest.  The real and imaginary part refs (i.e., %re and %im)
map to the components of a C-centric _Complex struct.  When one
has an array of _Complex struct, it may be more efficient to do
the copy than deal with any overhead that might arise from alignment.
This is just a guess as I need to go (re)study gfortran's internals.

If I compile your code with -fdump-tree-original, the call to
FUBAR is translated to

fubar (&x.phi, &x.phi);

which confirms my guess that the issue involves passing the address
of x%phi(1) for both arguments.  I don't know if the middle-end can
be given &x.phi(1).re and &x.phi(1).im and a 4-byte stride.

The code from my example translate the call to

 fubar (&atmp.14, &atmp.17);

where atmp.14 and atmp.17 are the temporaries.

[Bug c++/62244] Function parameter should be in scope in its own default argument

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Just hit this with:

int foo(int x = (decltype(x)(42))) { return 0; }

[Bug c++/120012] [12/13/14/15/16 Regression] P1008R1 causes tail padding reuse in C++20 mode

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

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

Jason Merrill  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-04-29
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 CC||jason at gcc dot gnu.org

[Bug c++/120016] New: SIGSEGV ICE with modules related to instantiation of templates across partition units (case 3)

[miuna.oshino at gmail dot com via Gcc-bugs]

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

Bug ID: 120016
   Summary: SIGSEGV ICE with modules related to instantiation of
templates across partition units (case 3)
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miuna.oshino at gmail dot com
  Target Milestone: ---

Created attachment 61246
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61246&action=edit
Crash 3 project files + preprocessed source

Possible duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120014, though this is a different
crash message.

> In all cases g++ crashes because of including certain std headers in `hewwo` 
> in the partition chain `hewwo -> uwu -> owo`.
> Many headers cause this, but we will use  as a scapegoat because it 
> is my sworn enemy
>  
> CRASH 3: some iterator stuff 
> - `hewwo`: Variable with 
> - `uwu`: Alias to DIFFERENT array **(no chrono)**
> - `owo`: **NOTHING**, but WITH 
> - Including  in all 3 fixes it.
> - Eerily similar again, wondering if it's just the same issue
> - **This one does give some information**

FAILED: CMakeFiles/meow.dir/owo.ixx.o CMakeFiles/meow.dir/meow-owo.gcm
/usr/local/bin/g++   -std=c++20 -freport-bug -Wall -Wextra -pedantic -MD -MT
CMakeFiles/meow.dir/owo.ixx.o -MF CMakeFiles/meow.dir/owo.ixx.o.d -fmodules-ts
-fmodule-mapper=CMakeFiles/meow.dir/owo.ixx.o.modmap -MD -fdeps-format=p1689r5
-x c++ -o CMakeFiles/meow.dir/owo.ixx.o -c /home/miuna/dev/crash-3/owo.ixx
In file included from /usr/local/include/c++/15.1.0/bits/stl_algobase.h:65,
 from /usr/local/include/c++/15.1.0/array:45,
 from /home/miuna/dev/crash-3/owo.ixx:3:
/usr/local/include/c++/15.1.0/bits/stl_iterator_base_types.h: In substitution
of ‘template using std::_RequireInputIter =
std::__enable_if_t<((bool)std::is_convertible::iterator_category,
std::input_iterator_tag>::value)> [with _InIter = char*]’:
/usr/local/include/c++/15.1.0/bits/basic_string.h:847:9:   required by
substitution of ‘template constexpr
std::__cxx11::basic_string::basic_string(_InputIterator, _InputIterator,
const std::allocator&) [with _InputIterator = char*;
 = ]’
  847 |typename = std::_RequireInputIter<_InputIterator>>
  |^~~~
/usr/local/include/c++/15.1.0/ext/string_conversions.h:119:14:   required from
‘_String __gnu_cxx::__to_xstring(int (*)(_CharT*, std::size_t, const _CharT*,
__va_list_tag*), std::size_t, const _CharT*, ...) [with _String =
std::__cxx11::basic_string; _CharT = char; std::size_t = long unsigned
int]’
  119 |   return _String(__s, __s + __len);
  |  ^
/usr/local/include/c++/15.1.0/bits/basic_string.h:4697:43:   required from here
 4697 | return __gnu_cxx::__to_xstring(&std::vsnprintf, __n,
  |~~~^~
 4698 |"%f", __val);
  |
/usr/local/include/c++/15.1.0/bits/stl_iterator_base_types.h:254:57: internal
compiler error: Segmentation fault
  254 |input_iterator_tag>::value>;
  | ^
0x22cc84f internal_error(char const*, ...)
/home/miuna/dev/gcc/gcc/diagnostic-global-context.cc:517
0xfe115f crash_signal
/home/miuna/dev/gcc/gcc/toplev.cc:322
0x7f8e4356032f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x78419a install_entity
/home/miuna/dev/gcc/gcc/cp/module.cc:8109
0x78419a decl_value
/home/miuna/dev/gcc/gcc/cp/module.cc:8657
0x8e8a94 tree_node
/home/miuna/dev/gcc/gcc/cp/module.cc:10062
0x8ed09c module_state::read_cluster(unsigned int)
/home/miuna/dev/gcc/gcc/cp/module.cc:16673
0x8edb67 module_state::load_section(unsigned int, binding_slot*)
/home/miuna/dev/gcc/gcc/cp/module.cc:20217
0x8edc1e module_state::lazy_load(unsigned int, binding_slot*)
/home/miuna/dev/gcc/gcc/cp/module.cc:21063
0x8e98d9 tree_node
/home/miuna/dev/gcc/gcc/cp/module.cc:10629
0x8ed02b module_state::read_cluster(unsigned int)
/home/miuna/dev/gcc/gcc/cp/module.cc:16528
0x8edb67 module_state::load_section(unsigned int, binding_slot*)
/home/miuna/dev/gcc/gcc/cp/module.cc:20217
0x8edc1e module_state::lazy_load(unsigned int, binding_slot*)
/home/miuna/dev/gcc/gcc/cp/module.cc:21063
0x8e98d9 tree_node
/home/miuna/dev/gcc/gcc/cp/module.cc:10629
0x8ed02b module_state::read_cluster(unsigned int)
/home/miuna/dev/gcc/gcc/cp/module.cc:16528
0x8edb67 module_state::load_section(unsigned int, binding_slot*)
/home/miuna/dev/gcc/gcc/

[Bug ipa/120006] [15 Regression] wrong code with -O2 -fipa-pta

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

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

--- Comment #6 from Sam James  ---
(In reply to Avraham Hollander from comment #5)
> So it could be code from either of those files. How would you narrow that
> down further?

What I usually do is:
* Build it manually (git clone ... && cd ... && ./autogen.sh && ./configure &&
make, make sure The Thing works)
* Build it again w/ `make clean && ./configure CFLAGS="-O2 -fipa-pta" && make`
(or whatever flags), make sure I can reproduce
* make clean, git clean -fdx to clean up
* mkdir build-{good,bad,maybe}
* cd into each of those, do ~/git/util-linux/configure CFLAGS="-O2 -fipa-pta"
for bad, do ~/git/util-linux/configure for good & maybe
* get a list of differing objects between build-good/ and build-bad/
* bisect the list of differing objects by copying and rerunning make (inside
build-maybe)

But that's when I have no idea. If I have a clue or idea that it's in a
specific file, I may modify the build system first to just add -fipa-pta for a
single file or object to see if it works. Or I'll read the build log from a
regular build, and re-run the commands involved (put them in a script first,
make sure it works) to make each object + relink the executable, then tweak it.

(This is a rough outline of what I'm doing now.)

If you want to very quickly confirm (sort of -- see below (*)), you can read
the build.log, re-run that fsck-fsck.o comman with -fno-ipa-pta appended, then
run the command which linked fsck. Does it work now? Repeat with
fsck-monotonic.o to be sure.

(*) This isn't strictly accurate because it could be something inside
libmount.la libblkid.la libcommon.la.

[Bug ipa/120006] [15 Regression] wrong code with -O2 -fipa-pta

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

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

Sam James  changed:

   What|Removed |Added

  Known to fail||15.1.0, 16.0
   Keywords||needs-reduction
  Known to work||14.2.1
   Target Milestone|--- |15.2

[Bug ipa/120006] [15/16 Regression] wrong code with -O2 -fipa-pta

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

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

--- Comment #10 from Sam James  ---
It's definitely related to the x* functions. Using __builtin_XXX() instead
makes it work.

[Bug c++/120017] Nested diagnostics could be slightly improved for concepts-related diagnostics

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||67491
   Severity|normal  |enhancement


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug target/99217] [MIPS] wrong function entry with -fpatchable-function-entry

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #8 from chenglulu  ---
Patch https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682268.html can fix
this bug

[Bug c++/120012] [12/13/14/15/16 Regression] P1008R1 causes tail padding reuse in C++20 mode

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

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

--- Comment #1 from Jakub Jelinek  ---
Tried clang++ on godbolt and it has the C++17 layout for all language modes.

[Bug ipa/120018] New: internal compiler error: in redirect_to_unreachable, at ipa-fnsummary.cc:258 for 32-bits

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

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

Bug ID: 120018
   Summary: internal compiler error: in redirect_to_unreachable,
at ipa-fnsummary.cc:258 for 32-bits
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dkm at gcc dot gnu.org
  Target Milestone: ---

Running the rust testsuite with -m32 on x86_64 triggers 2 ICE:

 /.../git/gcc-master/build/gcc/testsuite/rust10/../../gccrs
-B.../git/gcc-master/build/gcc/testsuite/rust10/../../
/.../git/gcc-master/gcc/testsuite/rust/execute/torture/derive_clone_enum1.rs
-m32 -fdiagnostics-plain-output
-frust-incomplete-and-experimental-compiler-do-not-use -O1 -lm -o
./derive_clone_enum1.exe
during IPA pass: inline
crab1: internal compiler error: in redirect_to_unreachable, at
ipa-fnsummary.cc:258
0x38f10b1 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x38d9cff fancy_abort(char const*, int, char const*)
../../gcc/diagnostic.cc:1748
0x2c61577 redirect_to_unreachable
../../gcc/ipa-fnsummary.cc:258
0x2c61577 edge_set_predicate
../../gcc/ipa-fnsummary.cc:290
0x2c52390 remap_edge_summaries
../../gcc/ipa-fnsummary.cc:4355
0x2c55bdf ipa_merge_fn_summary_after_inlining(cgraph_edge*)
../../gcc/ipa-fnsummary.cc:4519
0x2c9942f inline_call(cgraph_edge*, bool, vec*,
int*, bool, bool*)
../../gcc/ipa-inline-transform.cc:522
0x2c80250 inline_to_all_callers_1
../../gcc/ipa-inline.cc:2612
0x2c80250 inline_to_all_callers
../../gcc/ipa-inline.cc:2637
0x2c81e1a cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/cgraph.h:3434
0x2c81e1a ipa_inline
../../gcc/ipa-inline.cc:2962
0x2c81e1a execute
../../gcc/ipa-inline.cc:3291

Failing assert is:
 258   │   gcc_checking_assert (lookup_attribute ("cold",
 259   │  DECL_ATTRIBUTES (target->decl)));

(gdb) call debug_tree(target->decl)
 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7722a0a8
arg-types >
pointer_to_this >
public external built-in QI :0:0
align:8 warn_if_not_align:0 built-in: BUILT_IN_NORMAL:BUILT_IN_UNREACHABLE>

Or maybe the rust frontend is doing something incorrect with
__builtin_unreachable?

[Bug fortran/119986] Complex array part references are being passed incorrectly to a procedure

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #3 from kargls at comcast dot net ---
Additional data point.  This gives the correct answer.

program main
   integer j
   complex, allocatable :: x(:)
   x= [(cmplx(j,-j), j=1, 4)]
   call fubar(x%re, x%im)
   contains
  subroutine fubar(u, v)
 real, intent(in) :: u(:), v(:)
 print *, 'phi%re:', u
 print *, 'phi%im:', v
  end subroutine
end program

% gfcx -o z a.f90 && ./z
  phi%re:   1.   2.   3.   4.000
  phi%im:  -1.  -2.  -3.  -4.

So, resolving the ultimate allocatable complex component seems to be involved.

Also note, that the above generates the expected temporary arrays.

% gfcx -o z -Warray-temporaries a.f90
a.f90:21:14:

   21 |call fubar(x%re, x%im)
  |  1
Warning: Creating array temporary at (1) [-Warray-temporaries]
a.f90:21:20:

   21 |call fubar(x%re, x%im)
  |1
Warning: Creating array temporary at (1) [-Warray-temporaries]

Neil's original code does not generate temporaries and appears
to be passing the address of x(1)%phi%re.

[Bug rtl-optimization/92080] Missed CSE of _mm512_set1_epi8(c) with _mm256_set1_epi8(c)

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-271-gd1cada7481420a23fbec525548ef5bdf64839a34
Author: H.J. Lu 
Date:   Fri Nov 29 18:22:14 2024 +0800

x86: Add a pass to remove redundant all 0s/1s vector load

For all different modes of all 0s/1s vectors, we can use the single widest
all 0s/1s vector register for all 0s/1s vector uses in the whole function.
Add a pass to generate a single widest all 0s/1s vector set instruction at
entry of the nearest common dominator for basic blocks with all 0s/1s
vector uses.  On Linux/x86-64, in cc1plus, this patch reduces the number
of vector xor instructions from 4803 to 4714 and pcmpeq instructions from
144 to 142.

NB: PR target/92080 and PR target/117839 aren't same.  PR target/117839
is for vectors of all 0s and all 1s with different sizes and different
components.  PR target/92080 is for broadcast of the same component to
different vector sizes.  This patch covers only all 0s and all 1s cases
of PR target/92080.

gcc/

PR target/92080
PR target/117839
* config/i386/i386-features.cc (ix86_place_single_vector_set):
New function.
(remove_partial_avx_dependency): Use it.
(ix86_get_vector_load_mode): New function.
(replace_vector_const): Likewise.
(remove_redundant_vector_load): Likewise.
(pass_data_remove_redundant_vector_load): Likewise.
(pass_remove_redundant_vector_load): Likewise.
(make_pass_remove_redundant_vector_load): Likewise.
* config/i386/i386-passes.def: Add
pass_remove_redundant_vector_load after
pass_remove_partial_avx_dependency.
* config/i386/i386-protos.h
(make_pass_remove_redundant_vector_load): New.
* config/i386/i386.cc (ix86_modes_tieable_p): Return true for
narrower non-scalar-integer modes in SSE registers.

gcc/testsuite/

PR target/92080
PR target/117839
* gcc.target/i386/pr117839-1a.c: New test.
* gcc.target/i386/pr117839-1b.c: Likewise.
* gcc.target/i386/pr117839-2.c: Likewise.
* gcc.target/i386/pr92080-1.c: Likewise.
* gcc.target/i386/pr92080-2.c: Likewise.
* gcc.target/i386/pr92080-3.c: Likewise.

Signed-off-by: H.J. Lu 

[Bug target/117839] Redundant vector XOR instructions

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-271-gd1cada7481420a23fbec525548ef5bdf64839a34
Author: H.J. Lu 
Date:   Fri Nov 29 18:22:14 2024 +0800

x86: Add a pass to remove redundant all 0s/1s vector load

For all different modes of all 0s/1s vectors, we can use the single widest
all 0s/1s vector register for all 0s/1s vector uses in the whole function.
Add a pass to generate a single widest all 0s/1s vector set instruction at
entry of the nearest common dominator for basic blocks with all 0s/1s
vector uses.  On Linux/x86-64, in cc1plus, this patch reduces the number
of vector xor instructions from 4803 to 4714 and pcmpeq instructions from
144 to 142.

NB: PR target/92080 and PR target/117839 aren't same.  PR target/117839
is for vectors of all 0s and all 1s with different sizes and different
components.  PR target/92080 is for broadcast of the same component to
different vector sizes.  This patch covers only all 0s and all 1s cases
of PR target/92080.

gcc/

PR target/92080
PR target/117839
* config/i386/i386-features.cc (ix86_place_single_vector_set):
New function.
(remove_partial_avx_dependency): Use it.
(ix86_get_vector_load_mode): New function.
(replace_vector_const): Likewise.
(remove_redundant_vector_load): Likewise.
(pass_data_remove_redundant_vector_load): Likewise.
(pass_remove_redundant_vector_load): Likewise.
(make_pass_remove_redundant_vector_load): Likewise.
* config/i386/i386-passes.def: Add
pass_remove_redundant_vector_load after
pass_remove_partial_avx_dependency.
* config/i386/i386-protos.h
(make_pass_remove_redundant_vector_load): New.
* config/i386/i386.cc (ix86_modes_tieable_p): Return true for
narrower non-scalar-integer modes in SSE registers.

gcc/testsuite/

PR target/92080
PR target/117839
* gcc.target/i386/pr117839-1a.c: New test.
* gcc.target/i386/pr117839-1b.c: Likewise.
* gcc.target/i386/pr117839-2.c: Likewise.
* gcc.target/i386/pr92080-1.c: Likewise.
* gcc.target/i386/pr92080-2.c: Likewise.
* gcc.target/i386/pr92080-3.c: Likewise.

Signed-off-by: H.J. Lu 

[Bug target/117839] Redundant vector XOR instructions

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

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |16.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 16.

[Bug target/117547] FAIL: gcc.target/i386/*-pr93673.c without TARGET_PROMOTE_PROTOTYPES

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |16.0
 Resolution|--- |FIXED

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 16.

[Ada] incorrectly specified array of record aggregates in protected object causes bug box in GNAT 12.2.0

[babiak via Gcc-bugs]

(Sorry if I included too much information, this is my first time making 
a manual bug report by email.)


I ran into this error when I forgot to specify all the elements in an 
array aggregate, but instead of a compiler error or warning, I got a bug 
box. To be specific: Inside a protected object, I have an array of 
records. Instead of specifying it with a full list of elements, I forgot 
to say "others =>" before the record aggregate I intended to use for all 
elements. That is, `variable: array_type:= [[record_element=>Value]];`. 
This triggered a bug box, saying the error was detected at the beginning 
of the protected object's spec.


The minimal example I came up with is attached.

The bug appears for both discriminated and non-discriminated records, 
but only if the variable definition is inside a protected object. Or at 
least, I haven't found any other ways to trigger it. The output of 
gnatmake, complete with bug box is below:


=== BEGIN ===
$ gnatmake bug -gnat2022
x86_64-linux-gnu-gcc-12 -c -gnat2022 bug.adb
+===GNAT BUG DETECTED==+
| 12.2.0 (x86_64-linux-gnu) Storage_Error stack overflow or erroneous 
memory access|

| Error detected at bug.adb:11:5   |
| Compiling bug.adb|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

bug.adb

bug.adb:13:35: warning: too few elements for type "struct_array" defined 
at line 9 [enabled by default]
bug.adb:13:35: warning: expected 2 elements; found 1 element [enabled by 
default]

compilation abandoned
gnatmake: "bug.adb" compilation error
=== END ===

As can be seen, the exact command line passed to GCC was 
"x86_64-linux-gnu-gcc-12 -c -gnat2022 bug.adb". I have compiled this 
code with various other flags, and it persists (the gnat2022 flag is 
needed for the aggregate syntax I'm using).


I am running a Devuan linux machine (debian-based, without Systemd), 
with `uname -a` saying "Linux hostname 6.1.0-32-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.129-1 (2025-03-06) x86_64 GNU/Linux"


The output of `gcc -v` is below:

=== BEGIN ===
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/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='Debian 
12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-12 
--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-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-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr 
--enable-offload-defaulted --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)
=== END ===

I would expect to either have the "too few elements for type" warning to 
cause an error, or the compiler to compile normally and fail at runtime 
with a constraint_error: range check failed.
Or maybe fail with some other error, such as about how the protected 
object doesn't have a body (it can have a body, it's just not needed for 
the bug to appear).

Instead, I get the bug box, as included above.

Sorry again if I included the wrong information, or formatted the email 
wrong or anything like that. It's my first time using a gnu mailing list.-- compile with gnatmake -gnat2022
procedure bug is
type index is range 1..

[Bug target/111657] Memory copy with structure assignment from named address space should be improved

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r16-276-gaa29654b1128a572c97fcaba94095f493662a0db
Author: Uros Bizjak 
Date:   Tue Apr 29 10:25:45 2025 +0200

i386: Allow string instructions from non-default address space [PR111657]

MOVS instructions allow segment override of their source operand, e.g.:

rep movsq %gs:(%rsi), (%rdi)

where %rsi is the address of the source location (with %gs segment
override)
and %rdi is the address of the destination location.

The testcase improves from (-O2 -mno-sse -mtune=generic):

xorl%eax, %eax
.L2:
movl%eax, %edx
addl$8, %eax
movq%gs:m(%rdx), %rcx
movq%rcx, (%rdi,%rdx)
cmpl$240, %eax
jb  .L2
ret

to:
movl$m, %esi
movl$30, %ecx
rep movsq %gs:(%rsi), (%rdi)
ret

PR target/111657

gcc/ChangeLog:

* config/i386/i386-expand.cc (alg_usable_p): Remove have_as bool
argument and add dst_as and src_as address space arguments.  Reject
libcall algorithm with dst_as and src_as in the non-default address
spaces.  Reject rep_prefix_{1,4,8}_byte algorithms with dst_as in
the non-default address space.
(decide_alg): Remove have_as bool argument and add dst_as and
src_as
address space arguments.  Update calls to alg_usable_p.
(ix86_expand_set_or_cpymem): Update call to decide_alg.
* config/i386/i386.md (strmov): Do not fail if operand[3] (source)
is in the non-default address space.  Expand with
gen_strmov_singleop
only when operand[1] (destination) is in the default address space.
(*strmovdi_rex_1): Determine memory operands from insn pattern.
Allow only when destination is in the default address space.
Rewrite asm template to use explicit operands.
(*strmovsi_1): Ditto.
(*strmovhi_1): DItto.
(*strmovqi_1): Ditto.
(*rep_movdi_rex64): Ditto.
(*rep_movsi): Ditto.
(*rep_movqi): Ditto.
(*strsetdi_rex_1): Determine memory operands from insn pattern.
Allow only when destination is in the default address space.
(*strsetsi_1): Ditto.
(*strsethi_1): Ditto.
(*strsetqi_1): Ditto.
(*rep_stosdi_rex64): Ditto.
(*rep_stossi): Ditto.
(*rep_stosqi): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr111657-1.c: New test.

[Bug target/111657] Memory copy with structure assignment from named address space should be improved

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #13 from Uroš Bizjak  ---
Fully implemented for gcc-16.

[Bug tree-optimization/119960] [15/16 Regression] vectorizer seems not to do as much any more since r15-5863

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

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

--- Comment #7 from Richard Biener  ---
So I do have a patch amending the r15-5863 revision to allow vectorizing the
cases again but it regresses gcc.dg/vect/pr116352.c (the testcase the code
was added for) since we run into a similar issue in SLP scheduling then,
which tries to order "unordered" SSA defs with code like

/* We are emitting all vectorized stmts in the same place and
   the last one is the last.
   ???  Unless we have a load permutation applied and that
   figures to re-use an earlier generated load.  */
unsigned j;
tree vdef;
FOR_EACH_VEC_ELT (SLP_TREE_VEC_DEFS (child), j, vdef)
  {
gimple *vstmt = SSA_NAME_DEF_STMT (vdef);
if (!last_stmt
|| vect_stmt_dominates_stmt_p (last_stmt, vstmt))
  last_stmt = vstmt;
  }

where the main issue is that we do not verify we actually _can_ schedule
the SLP graph onto the existing CFG.  Without inserting PHIs, specifically
LC PHIs, where necessary when for example instead trying to insert at the
hopefully single block of the dominance frontier.

So for now we have to accept the regression and eventually get to the TODO
to actually implement a scheduling feasability check (since we already
fail to ensure trivial schedulability given vectors eventually are combined
from defs from different parts of the CFG).

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Unrolling the infinite loop is what happens.

Anyways as mentioned the infinite loop is expected so closing as invalid.

[Bug c/119317] Named loops (C2y) do not compile with -O1 and -ggdb2 or higher

[Chris.Bazley at arm dot com via Gcc-bugs]

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

--- Comment #5 from Chris Bazley  ---
Patch has been emailed to gcc-patc...@gcc.gnu.org for review.

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Without -fpic/-fPIC, the code gcc outputs will never be always position
independent. So using a constant pool for the address is correct.

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

[gcc--- via Gcc-bugs]

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

Thomas Weißschuh  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from Thomas Weißschuh  ---
(In reply to Andrew Pinski from comment #1)
> Without -fpic/-fPIC, the code gcc outputs will never be always position
> independent.

With -fpic/-fPIC the same thing happens.

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

[vincenzo.romano at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vincenzo Romano  ---
Id the double amoor op intentional?

If so, why?

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

--- Comment #4 from Jonathan Wakely  ---
It stopped aborting with r14-2709-g65ff4a45b11b5ab13ef849bd5721ab28ff316202

Author: Jan Hubicka
AuthorDate: Fri Jul 21 13:54:23 2023

loop-ch improvements, part 5

Currently loop-ch skips all do-while loops.  But when loop is not do-while
in addition to original goal of turining it to do-while it can do
additional
things:
 1) move out loop invariant computations
 2) duplicate loop invariant conditionals and eliminate them in loop body.
 3) prove that some exits are always true in first iteration
and can be skipped

Most of time 1 can be done by lim (exception is when the invariant
computation
is conditional). For 2 we however don't really have other place doing it
except
for loop unswitching that is more expensive (it will duplicate the loop and
then optimize out one path to non-loop).
3 can be done by loop peeling but it is also more expensive by duplicating
full
loop body.

This patch improves heuristics by not giving up on do-while loops and
trying
to find sequence of BBs to duplicate to obtain one of goals:
 - turn loop to do-while
 - eliminate invariant conditional in loop body
 - do partial "peeling" as long as code optimizes enough so this does not
   increase code size.

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

--- Comment #6 from Jonathan Wakely  ---
Using -fno-finite-loops prevents the assertion from failing:


-ffinite-loops

  Assume that a loop with an exit will eventually take the exit and not loop
indefinitely.
  This allows the compiler to remove loops that otherwise have no side-effects,
not
  considering eventual endless looping as such.

  This option is enabled by default at -O2 for C++ with -std=c++11 or higher.


I think GCC is behaving as expected (although I'm not sure why r14-2709 changed
it).

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

--- Comment #7 from Jonathan Wakely  ---
N.B. with -O3 we just exit without aborting or looping, even after r14-2709.
That's OK, because the behaviour is undefined. It would be nice if we inserted
an unreachable or a trap that -fsanitize=undefined could diagnose.

Use -fno-finite-loops to make GCC accept the code as valid.

[Bug target/113484] Add support for _Float16 type on PowerPC

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from John Platts  ---
(In reply to Segher Boessenkool from comment #4)
> Ah, this was about *actual* half-precision float, which indeed is 3.0
> (Power9).
> 
> But all the same holds: it needs to be added to the ABI before we can have a
> type for it, and it still won't be terribly useful (it will make for *slowe
> code*, not using fewer resources either).

There were plans to add support for the _Float16 and __vector _Float16 types to
the POWER 64-bit ELF V2 ABI according to Version 1.4 of that specification that
can be found at https://files.openpower.foundation/s/aqwWeS3qmoaDyos.

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

--- Comment #5 from Jonathan Wakely  ---
It started aborting with r272234 aka r10-1052-gc29c92c789d938

Author: Feng Xue
AuthorDate: Thu Jun 13 05:17:42 2019

PR tree-optimization/89713 - Assume loop with an exit is finite

gcc/ChangeLog:

* doc/invoke.texi (-ffinite-loops): Document new option.
* common.opt (-ffinite-loops): New option.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Mark
IFN_GOACC_LOOP calls as necessary.
* tree-ssa-loop-niter.c (finite_loop_p): Assume loop with an exit
is finite.
* omp-offload.c (oacc_xform_loop): Skip lowering if return value of
IFN_GOACC_LOOP call is not used.
* opts.c (default_options_table): Enable -ffinite-loops at -O2+.

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #8 from Jonathan Wakely  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2809r3.html changed
the rules (voted into C++26 and as a DR against previous standards). But it
only affects certain syntactic forms of loop, and this goto loop doesn't count.

[Bug c++/119806] OpenACC, OpenMP 'target' offloading vs. C++ 'typeinfo' parts

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

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

--- Comment #2 from Thomas Schwinge  ---
Similarly (I suppose, but have not checked the details), OpenMP_VV
'tests/5.0/application_kernels/declare_target_base_and_derived_class.cpp':

GCN:

ld: error: undefined symbol: vtable for S1
>>> referenced by /tmp/ccWZSCBY.o:(.data.rel.ro.local+0x0)
>>> the vtable symbol may be undefined because the class is missing its key
function (see https://lld.llvm.org/missingkeyfunction)
collect2: error: ld returned 1 exit status
gcn mkoffload: fatal error:
$T/install/bin/x86_64-pc-linux-gnu-accel-amdgcn-amdhsa-gcc returned 1 exit
status

nvptx:

ptxas /tmp/cci1PjSv.o, line 397; error   : Unknown symbol '_ZTV2S1'
ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
nvptx mkoffload: fatal error: x86_64-pc-linux-gnu-accel-nvptx-none-gcc
returned 1 exit status

$ c++filt _ZTV2S1
vtable for S1

[Bug c++/119844] Incomplete types are displayed after the import module

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||nshead at gcc dot gnu.org

--- Comment #2 from Nathaniel Shead  ---
I haven't attempted to fully reproduce, but it appears to me you have something
like the following:

  // user.cpp
  export module User;
  export struct User {
int value;
  };

  // main.cpp
  struct User;
  struct MainWindow {
User* u;
  };
  import User;
  int foo(MainWindow m) {
return m.u->value;
  }

$ g++-15 -fmodules -S user.cpp main.cpp
main.cpp: In function ‘int foo(MainWindow)’:
main.cpp:7:13: error: invalid use of incomplete type ‘struct User’
7 |   return m.u->value;
  | ^~
main.cpp:1:8: note: forward declaration of ‘struct User’
1 | struct User;
  |^~~~

This error is expected (though the diagnostic could definitely be improved!):
'User' (in main.cpp) and 'User@User' (in user.cpp) are unrelated, distinct
types; the former belonging to the global module, and the latter attached to
the module 'User'.  You can see this by comparing e.g.:

  // main.cpp
  struct User;
  import User;
  User u;

$ g++-15 -fmodules -S user.cpp main.cpp
main.cpp:3:1: error: reference to ‘User’ is ambiguous
3 | User u;
  | ^~~~
In module User, imported at main.cpp:2:
user.cpp:2:15: note: candidates are: ‘struct User@User’
2 | export struct User {
  |   ^~~~
main.cpp:1:8: note: ‘struct User’
1 | struct User;
  |^~~~

To fix the issue, you could defined user.cpp as something like this:

  // user.cpp
  export module User;
  export extern "C++" struct User {
int value;
  };

The 'extern "C++"' ensures that 'User' is declared attached to the global
module.

I'll leave this PR open for now for the diagnostic issue, however, as I imagine
this to be a common mistake, and we should be able to detect this and emit some
kind of note pointing to the conflicting type.

[Bug middle-end/120003] New: Missed Optimisation / Regression

[phdiv at fastmail dot fm via Gcc-bugs]

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

Bug ID: 120003
   Summary: Missed Optimisation / Regression
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: phdiv at fastmail dot fm
  Target Milestone: ---

Consider the following code:

  extern bool g(int);

  bool f(){
bool retval = false;
for(int i=0; i<1'000'000; ++i)
retval = retval || g(i);
return retval;
  }

Up until GCC 11, it was recognised that the loop can be exited as soon
as the first call to  g  returns true. Since GCC 12, and present up to 15,
the loop keeps on incrementing needlessly.

https://godbolt.org/z/q5qKbcoMG

[Bug target/119235] Argument pointer survives LRA with -m31 -mzarch

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Stefan Schulze Frielinghaus
:

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

commit r12-11075-gd41ce9f7c392d5110a63d61c4c85fb7a5f2f
Author: Stefan Schulze Frielinghaus 
Date:   Fri Mar 21 10:29:19 2025 +0100

s390: Accept only Pmode for registers AP/FP/RA [PR119235]

gcc/ChangeLog:

PR target/119235
* config/s390/s390.cc (s390_hard_regno_mode_ok): Accept only
Pmode for registers AP/FP/RA.

(cherry picked from commit 2b383ae2a6e5fc0530bfd8b86ad0e6b27e760bd2)

[Bug c/120001] New: On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

[vincenzo.romano at gmail dot com via Gcc-bugs]

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

Bug ID: 120001
   Summary: On RISC-V with -O2 and -O3 __sync_or_and_fetch in a
loop renders as an endless loop and multiple amoor
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.romano at gmail dot com
  Target Milestone: ---

This code:

#define LOCK_BIT ((unsigned long)(1ul<<(8*sizeof(long)-1)))

void lock_hold(long* lock) {
  while(__sync_or_and_fetch(lock,LOCK_BIT) < 0);
  __sync_synchronize();
}


with -O2 and -O3 renders as:

lock_hold:
li  a5,-1
sllia5,a5,63
.L2:
amoor.d.aqrla4,a5,0(a0)
amoor.d.aqrla4,a5,0(a0)
j   .L2

(Please also note the double amoor instruction).
Similarly, with -Os it renders as:

lock_hold:
li  a5,-1
sllia5,a5,63
.L2:
amoor.d.aqrla4,a5,0(a0)
j   .L2

(Please also note the single amoor instruction).

Instead, with -O1 I get more reasonably:

lock_hold:
li  a5,-1
sllia5,a5,63
.L2:
amoor.d.aqrla4,a5,0(a0)
or  a5,a5,a4
blt a5,zero,.L2
fence   rw,rw
ret

With -O0 I get something similar to the code generated with -O1.

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #15 from Thomas Schwinge  ---
*** Bug 110800 has been marked as a duplicate of this bug. ***

[Bug target/119235] Argument pointer survives LRA with -m31 -mzarch

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #5 from Stefan Schulze Frielinghaus  
---
Fixed.

gcc-bugs@gcc.gnu.org

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r16-281-gfc62834533f357125b9c1934f80c2ba249adbf9e
Author: Richard Biener 
Date:   Tue Apr 29 11:06:36 2025 +0200

tree-optimization/119997 - &ptr->field no longer subject to PRE

The following makes PRE handle &ptr->field the same as VN by
treating it as a POINTER_PLUS_EXPR when possible and thus as
'nary'.  To facilitate this the patch splits out vn_pp_nary_for_addr
and adds const overloads for vec::last.  The patch also avoids
handling an effective zero offset as POINTER_PLUS_EXPR.

PR tree-optimization/119997
* vec.h (vec::last): Provide const overload.
(vec::last): Likewise.
* tree-ssa-sccvn.h (vn_pp_nary_for_addr): Declare.
* tree-ssa-sccvn.cc (vn_pp_nary_for_addr): Split out from ...
(vn_reference_lookup): ... here.
(vn_reference_insert): ... and duplicate here.  Do not handle
zero offset as POINTER_PLUS_EXPR.
* tree-ssa-pre.cc (compute_avail): Implement
ADDR_EXPR-as-POINTER_PLUS_EXPR special casing.

* gcc.dg/tree-ssa/ssa-pre-35.c: New testcase.

gcc-bugs@gcc.gnu.org

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||13.1.0, 15.1.0
Summary|[13/14/15/16 Regression]|[13/14/15 Regression] PRE
   |PRE no longer hoists|no longer hoists
   |&ptr->field |&ptr->field
  Known to work||12.4.0, 16.0

--- Comment #3 from Richard Biener  ---
Fixed on trunk, I don't think backporting is worthwhile.

[Bug libstdc++/119427] std::erase_if(std::flat_map) does not work

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.3

[Bug libstdc++/119427] std::erase_if(std::flat_map) does not work

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r16-282-gaa93272cfd2233858da0792761387cc27f4d5ff3
Author: Patrick Palka 
Date:   Tue Apr 29 08:21:35 2025 -0400

libstdc++: Fix availability of std::erase_if(std::flat_foo) [PR119427]

These std::erase_if overloads were wrongly implemented as hidden
friends, visible only via ADL, so erase_if(x) would work but not
std::erase_if(x).

PR libstdc++/119427

libstdc++-v3/ChangeLog:

* include/std/flat_map (_Flat_map_impl::erase_if): Replace
this hidden friend with ...
(_Flat_map_impl::_M_erase_if): ... this member function.
(flat_map): Export _Flat_map_impl::_M_erase_if.
(erase_if(flat_map)): Define.
(flat_multimap): Export _Flat_map_impl::_M_erase_if.
(erase_if(flat_multimap)): Define.
* include/std/flat_set (_Flat_set_impl::erase_if): Replace
with ...
(_Flat_set_impl::_M_erase_if): ... this member function.
(flat_set): Export _Flat_set_impl::_M_erase_if.
(erase_if(flat_set)): Define.
(flat_multiset): Export _Flat_set_impl::_M_erase_if.
(erase_if(flat_multiset)): Define.
* testsuite/23_containers/flat_map/1.cc (test07): New test.
* testsuite/23_containers/flat_multimap/1.cc (test07): New test.
* testsuite/23_containers/flat_multiset/1.cc (test09): New test.
* testsuite/23_containers/flat_set/1.cc (test09): New test.

Reviewed-by: Jonathan Wakely 

[Bug c++/104734] -isystem hides -Woverloaded-virtual warning

[eugene.shalygin at gmail dot com via Gcc-bugs]

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

Eugene Shalygin  changed:

   What|Removed |Added

 CC||eugene.shalygin at gmail dot 
com

--- Comment #6 from Eugene Shalygin  ---
Moreover, if the inherited class is not in the system header, to silence the
warning one has to put the diagnostic ignoring pragma before the function in
the base class, and not at the point when the mistake is made:
https://godbolt.org/z/984qfzzcf

[Bug target/119900] [16 regression] imagick slowdown with -Ofast -march=native -fprofile-use since r16-39-gf6859fb621179e (interaction of rpad and late-combine)

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
Summary|[16 regression] imagick |[16 regression] imagick
   |slowdown with -Ofast|slowdown with -Ofast
   |-march=native -fprofile-use |-march=native -fprofile-use
   |since   |since
   |r16-39-gf6859fb621179e  |r16-39-gf6859fb621179e
   ||(interaction of rpad and
   ||late-combine)
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-29

--- Comment #4 from Jan Hubicka  ---
The problem is interaction of the size_costs change. Either this patch
reverting this change:

diff --git a/gcc/config/i386/x86-tune-costs.h
b/gcc/config/i386/x86-tune-costs.h
index cddcf617304..a2512c7209a 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -121,17 +121,17 @@ struct processor_costs ix86_size_cost = {/* costs for
tuning for size */
   COSTS_N_BYTES (2),   /* cost of FCHS instruction.  */
   COSTS_N_BYTES (2),   /* cost of FSQRT instruction.  */

-  COSTS_N_BYTES (4),   /* cost of cheap SSE instruction.  */
-  COSTS_N_BYTES (4),   /* cost of ADDSS/SD SUBSS/SD insns.  */
-  COSTS_N_BYTES (4),   /* cost of MULSS instruction.  */
-  COSTS_N_BYTES (4),   /* cost of MULSD instruction.  */
-  COSTS_N_BYTES (4),   /* cost of FMA SS instruction.  */
-  COSTS_N_BYTES (4),   /* cost of FMA SD instruction.  */
-  COSTS_N_BYTES (4),   /* cost of DIVSS instruction.  */
-  COSTS_N_BYTES (4),   /* cost of DIVSD instruction.  */
-  COSTS_N_BYTES (4),   /* cost of SQRTSS instruction.  */
-  COSTS_N_BYTES (4),   /* cost of SQRTSD instruction.  */
-  COSTS_N_BYTES (4),   /* cost of CVTSS2SD etc.  */
+  COSTS_N_BYTES (2),   /* cost of cheap SSE instruction.  */
+  COSTS_N_BYTES (2),   /* cost of ADDSS/SD SUBSS/SD insns.  */
+  COSTS_N_BYTES (2),   /* cost of MULSS instruction.  */
+  COSTS_N_BYTES (2),   /* cost of MULSD instruction.  */
+  COSTS_N_BYTES (2),   /* cost of FMA SS instruction.  */
+  COSTS_N_BYTES (2),   /* cost of FMA SD instruction.  */
+  COSTS_N_BYTES (2),   /* cost of DIVSS instruction.  */
+  COSTS_N_BYTES (2),   /* cost of DIVSD instruction.  */
+  COSTS_N_BYTES (2),   /* cost of SQRTSS instruction.  */
+  COSTS_N_BYTES (2),   /* cost of SQRTSD instruction.  */
+  COSTS_N_BYTES (2),   /* cost of CVTSS2SD etc.  */
   COSTS_N_BYTES (4),   /* cost of 256bit VCVTPS2PD etc.  */
   COSTS_N_BYTES (6),   /* cost of 512bit VCVTPS2PD etc.  */
   1, 1, 1, 1,  /* reassoc int, fp, vec_int, vec_fp. 
*/

or -fno-late-combine-instructions avoids the performance regression.

The internal loop of imagick is considered cold with FDO since train run does
not train it at all.  We end up changing:

@@ -1156,9 +1156,8 @@
callParseGeometry
vmovsd  16(%rsp), %xmm7
vmovsd  .LC30(%rip), %xmm4
-   vxorps  %xmm3, %xmm3, %xmm3
-   testb   $4, %al
vmovsd  %xmm7, 8(%rsp)
+   testb   $4, %al
jne .L210
 .L166: 
vmovapd %xmm4, %xmm2



jne .L211
 .L167: 
vmovsd  .LC31(%rip), %xmm5
-   vcvtusi2sdq %r13, %xmm3, %xmm1
+   vcvtusi2sdq %r13, %xmm1, %xmm1
vmulsd  %xmm5, %xmm1, %xmm0

So previously we clared xmm3 and used it in integer->fp conversions while after
the patch we don't do this resulting in false dependency on xmm1.
The clear is introduced by the i386 specific rpad pass that is disabling itself
for functions optimized for size, but in this case the function contains hold
and cold region, so it inserts xors also into cold part of the program.

bool
ix86_rpad_gate ()
{   
  return (TARGET_AVX
  && TARGET_SSE_PARTIAL_REG_DEPENDENCY
  && TARGET_SSE_MATH
  && optimize
  && optimize_function_for_speed_p (cfun));
}  

I suppose it would make sense to disable RPAD for cold regions of the program
(which would make situation worse for imagick though).

This is now undone by late combine pass:

trying to combine definition of r24 in:
  388: xmm4:V2DF=vec_merge(vec_duplicate(uns_float(r14:DI)),xmm3:V2DF,0x1)
into:
  486: xmm4

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #3 from Andrew Pinski  ---
.LC0:
.xword  hidden_symbol+65537

Is still valid for all shared libraries.

The problem is you want a DSO with no dynamic relocations but that won't work
here.

If you want that you should do the similar thing as what the 32bit compat does
for a similar reasons:
```
static __always_inline const struct vdso_time_data
*__arch_get_vdso_u_time_data(void)
{
const struct vdso_time_data *ret;

/*
 * This simply puts &_vdso_time_data into ret. The reason why we don't
use
 * `ret = _vdso_time_data` is that the compiler tends to optimise this
in a
 * very suboptimal way: instead of keeping &_vdso_time_data in a
register,
 * it goes through a relocation almost every time _vdso_time_data must
be
 * accessed (even in subfunctions). This is both time and space
 * consuming: each relocation uses a word in the code section, and it
 * has to be loaded at runtime.
 *
 * This trick hides the assignment from the compiler. Since it cannot
 * track where the pointer comes from, it will only use one relocation
 * where __aarch64_get_vdso_u_time_data() is called, and then keep the
 * result in a register.
 */
asm volatile("mov %0, %1" : "=r"(ret) : "r"(&vdso_u_time_data));

return ret;
}
```

[Bug c++/119964] [15/16 regression] GCC 15 does not delete explicitly-defaulted move constructor with (const T&&) parameter

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Mine then.

[Bug c/119317] Named loops (C2y) do not compile with -O1 and -ggdb2 or higher

[gandalf at winds dot org via Gcc-bugs]

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

--- Comment #6 from Byron Stanoszek  ---
I confirm that Chris's patch does indeed fix the compile issue.

Thanks!

[Bug middle-end/120003] [12/13/14/15/16 Regression] missed optimization around a loop with a checker

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

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

--- Comment #1 from Andrew Pinski  ---
Maybe r12-3453-g01b5038718056b024b370b74a874fbd92c5bbab3 .

[Bug target/120002] R_AARCH64_ABS64 emitted against hidden symbol

[gcc--- via Gcc-bugs]

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

Thomas Weißschuh  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Thomas Weißschuh  ---
(In reply to Andrew Pinski from comment #3)
> .LC0:
> .xword  hidden_symbol+65537
> 
> Is still valid for all shared libraries.
>
> The problem is you want a DSO with no dynamic relocations but that won't
> work here.

Is there another way to prevent GCC from emitting absolute relocations?
Similar to how this code works with clang or -mcmodel=small?

> If you want that you should do the similar thing as what the 32bit compat
> does for a similar reasons.

This is what I am doing for now:
https://lore.kernel.org/lkml/20250429-vdso-absolute-reloc-v1-1-987a0afd1...@linutronix.de/
Unfortunately this only fixes one single location. New ones may crop up at any
time.

It doesn't seem to me that the reasons are similar.
The compat code does it for efficiency while the non-compat code now needs it
for correctness.

If this behavior is expected then it could also affect all other architectures,
no?

[Bug tree-optimization/120003] [12/13/14/15/16 Regression] missed optimization around a loop with a checker

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.5
  Component|middle-end  |tree-optimization
 CC||amacleod at redhat dot com

[Bug middle-end/120003] [12/13/14/15/16 Regression] missed optimization around a loop with a checker

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

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

--- Comment #2 from Richard Biener  ---
I bet it's caused by some jump threading changes for FSM threading
opportunities.

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Vincenzo Romano from comment #4)
> Id the double amoor op intentional?
> 
> If so, why?

I said why:
Unrolling the infinite loop is what happens.

We copy the inner basic block of the loop to "unroll" it during bb reordering.
It happens on many targets but it is due to the infinite loop.

[Bug target/110800] [gcn] ICE (segfault) 'during RTL pass: jump' in delete_trivially_dead_insns -> count_reg_usage when C++ exceptions are enabled + used

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|--- |15.0

--- Comment #3 from Thomas Schwinge  ---
Resolved via commit r15-9470-gfe283dba774be57b705a7a871b000d2894d2e553 "GCN,
nvptx: Support '-mfake-exceptions', and use it for offloading compilation
[PR118794]", and for nvptx offloading additionally commit
r15-8719-g65b31b3fff2fced015ded1026733605f34053796 "nvptx: In offloading
compilation, special-case certain host-setup symbol aliases [PR101544]".

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

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

[vincenzo.romano at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Vincenzo Romano  ---
Please, mark this bug as INVALID.
At least for the endless loop part.
I am not sure about the double amoor instruction, though.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

  Attachment #61234|0   |1
is obsolete||

--- Comment #28 from LIU Hao  ---
Created attachment 61236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61236&action=edit
proposed patch #2

It might not be safe to decrease the preferred stack boundary, so let's keep it
as 16, but initialize `ix86_default_incoming_stack_boundary` to 4 bytes
instead.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

  Attachment #61236|0   |1
is obsolete||

--- Comment #29 from LIU Hao  ---
Created attachment 61237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61237&action=edit
proposed patch #3

[Bug c/120002] New: R_AARCH64_ABS64 emitted against hidden symbol

[gcc--- via Gcc-bugs]

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

Bug ID: 120002
   Summary: R_AARCH64_ABS64 emitted against hidden symbol
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g...@t-8ch.de
  Target Milestone: ---

Relocations against involving hidden symbols should be PC-relative.
However on aarch64 with -mcmodel=tiny an absolute relocation may be emitted if
the offset to the symbol exceeds 64KiB.

Reproducer:

$ cat test.c
extern char hidden_symbol[] __attribute__((visibility("hidden")));

void *function(void)
{
void *ptr;

ptr = &hidden_symbol;
/* Works until 64 * 1024 */
ptr += 64 * 1024 + 1;

return ptr;
}

$ aarch64-linux-gnu-gcc test.c -c -o test.o -mcmodel=tiny -O2
$ aarch64-linux-gnu-objdump --section .text --disassemble-all
--disassemble-zeroes --reloc test.o

test.o: file format elf64-littleaarch64


Disassembly of section .text:

 :
   0:   5840ldr x0, 8 
   4:   d65f03c0ret
   8:   udf #0
8: R_AARCH64_ABS64  hidden_symbol+0x10001
   c:   udf #0



Background:

This setup is used in the Linux vDSO to achieve completely position independent
code. Some recent refactors triggered this bug.
https://lore.kernel.org/lkml/aApGPAoctq_eoE2g@t14ultra/

[Bug target/120001] On RISC-V with -O2 and -O3 __sync_or_and_fetch in a loop renders as an endless loop and multiple amoor

[vincenzo.romano at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vincenzo Romano  ---
If I put __sync_fetch_and_or instead of __sync_or_and_fetch I objously get the
expected behavior as fas as the endless loop is concerned.

[Bug tree-optimization/120003] [12/13/14/15/16 Regression] missed optimization around a loop with a checker

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug target/119980] wrong aliasing decision with structure acces

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
 Ever confirmed|0   |1
   Last reconfirmed||2025-04-29
  Component|rtl-optimization|target
 Target||x86_64-*-*
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
Version|unknown |16.0

--- Comment #3 from Richard Biener  ---
Yes, it looks very very similar.

In peephole2 the redundant load/store pair keeping the = 2 store data
dependent on the later load vanishes (with -fdisable-rtl-combine, otherwise
combine deletes it, see PR101641).  Then sched2 comes along and
breaks things.

So, -fdisable-rtl-combine -fdisable-rtl-peephole2 fixes this.  Let's keep
this instance of the bug for the peephole2 bug.  These kind of peepholes
might not apply before scheduling at least - in reality after such
patterns -fno-strict-aliasing should be enforced.

;; Attempt to optimize away memory stores of values the memory already
;; has.  See PR79593.
(define_peephole2
  [(set (match_operand 0 "register_operand")
(match_operand 1 "memory_operand"))
   (set (match_operand 2 "memory_operand") (match_dup 0))]
  "!MEM_VOLATILE_P (operands[1])
   && !MEM_VOLATILE_P (operands[2])
   && rtx_equal_p (operands[1], operands[2])
   && !reg_overlap_mentioned_p (operands[0], operands[2])"
  [(set (match_dup 0) (match_dup 1))])

[Bug target/117547] FAIL: gcc.target/i386/*-pr93673.c without TARGET_PROMOTE_PROTOTYPES

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r16-270-ga0a64aa5da0af5ecb022675cdb9140ccfa098ce3
Author: H.J. Lu 
Date:   Tue Nov 12 09:03:31 2024 +0800

i386: Add ix86_expand_unsigned_small_int_cst_argument

When passing 0xff as an unsigned char function argument with the C frontend
promotion, expand_normal used to get

 constant
255>

and returned the rtx value using the sign-extended representation:

(const_int 255 [0xff])

But after

commit a670ebde3995481225ec62b29686ec07a21e5c10
Author: H.J. Lu 
Date:   Thu Nov 21 07:54:35 2024 +0800

Drop targetm.promote_prototypes from C, C++ and Ada frontends

expand_normal now gets

 constant 255>

and returns

 (const_int -1 [0x])

which doesn't work with the predicates nor the instruction templates which
expect the unsigned expanded value.  Extract the unsigned char and short
integer constants to return

(const_int 255 [0xff])

so that the expanded value is always unsigned, without the C frontend
promotion.

PR target/117547
* config/i386/i386-expand.cc
(ix86_expand_unsigned_small_int_cst_argument):
New function.
(ix86_expand_args_builtin): Call
ix86_expand_unsigned_small_int_cst_argument to expand the argument
before calling fixup_modeless_constant.
(ix86_expand_round_builtin): Likewise.
(ix86_expand_special_args_builtin): Likewise.
(ix86_expand_builtin): Likewise.

Signed-off-by: H.J. Lu 

[Bug target/119980] wrong aliasing decision with structure acces

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> Yes, it looks very very similar.
> 
> In peephole2 the redundant load/store pair keeping the = 2 store data
> dependent on the later load vanishes (with -fdisable-rtl-combine, otherwise
> combine deletes it, see PR101641).  Then sched2 comes along and
> breaks things.
> 
> So, -fdisable-rtl-combine -fdisable-rtl-peephole2 fixes this.  Let's keep
> this instance of the bug for the peephole2 bug.  These kind of peepholes
> might not apply before scheduling at least - in reality after such
> patterns -fno-strict-aliasing should be enforced.
> 
> ;; Attempt to optimize away memory stores of values the memory already
> ;; has.  See PR79593.
> (define_peephole2
>   [(set (match_operand 0 "register_operand")
> (match_operand 1 "memory_operand"))
>(set (match_operand 2 "memory_operand") (match_dup 0))]
>   "!MEM_VOLATILE_P (operands[1])
>&& !MEM_VOLATILE_P (operands[2])
>&& rtx_equal_p (operands[1], operands[2])
>&& !reg_overlap_mentioned_p (operands[0], operands[2])"
>   [(set (match_dup 0) (match_dup 1))])

Possibly the following would fix it (not sure where to place the required
#include of alias.h)

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index e170da3b0e6..3cfb54abbd0 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -28489,6 +28489,7 @@
   "!MEM_VOLATILE_P (operands[1])
&& !MEM_VOLATILE_P (operands[2])
&& rtx_equal_p (operands[1], operands[2])
+   && mems_same_for_tbaa_p (operands[1], operands[2])
&& !reg_overlap_mentioned_p (operands[0], operands[2])"
   [(set (match_dup 0) (match_dup 1))])

[Bug c++/119999] New: Wrong Pointer Comparison in GCC 10/11/12/13 with -Os/-Oz Flags

[bouncy12578 at gmail dot com via Gcc-bugs]

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

Bug ID: 11
   Summary: Wrong Pointer Comparison  in GCC 10/11/12/13 with
-Os/-Oz Flags
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bouncy12578 at gmail dot com
  Target Milestone: ---

***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc-13
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/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
13.1.0-8ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada
,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-l
inker-build-id --libexecdir=/usr/libexec --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap
--enable-clocale=gnu --e
nable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-defaul
t-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-13-IvzKaI/gcc
-13-13.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-IvzKaI/gcc-13-13.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --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 13.1.0 (Ubuntu 13.1.0-8ubuntu1~22.04)

***
Program:
$ cat a.cpp
#include 
int a = 0;
static int b = 1;

void f(int * p){ 
l:
assert (p == &a);
if (b)
goto l;
}
int * g(){
return &a;
}

int main(int argc, char* argv[]){
f(g());
return 0;
}

***
Command Lines:
$ gcc a.cpp -o a.out -Os && ./a.out
a.out: a.cpp:7: void f(int*): Assertion `p == &a' failed.
Aborted

fail in gcc 10/11/12/13 with -Os/-Oz

[Bug c++/119998] New: ICE (segfault) on missing constraint in redeclaration.

[luc.grosheintz at gmail dot com via Gcc-bugs]

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

Bug ID: 119998
   Summary: ICE (segfault) on missing constraint in redeclaration.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luc.grosheintz at gmail dot com
  Target Milestone: ---

Created attachment 61235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61235&action=edit
Preprocessed sources and compilation command.

The reproducer has also been setup on Godbolt:
https://godbolt.org/z/o8Y6rGWfq

The following invalid code causes a segfault in GCC trunk (e.g. commit
`1c0cbc1b300e08df5ebfce00a7195890d78f2064`):

```
struct A {
  template 
  struct B;
};

template 
requires true
struct A::B
{
  template
B(U u);
};

template
template
A::B::B(U u) {}
```
(the requires clause differs in the redeclaration.)

The error message is:
```
Segmentation fault
   16 | A::B::B(U u) {}
  |   ^
0x29720df internal_error(char const*, ...)
../../gcc-bug/gcc/diagnostic-global-context.cc:517
0x145866f crash_signal
../../gcc-bug/gcc/toplev.cc:321
0xbd4fed cp_printer
../../gcc-bug/gcc/cp/error.cc:4689
0x2995638 format_phase_2
../../gcc-bug/gcc/pretty-print.cc:2157
0x2995638 pretty_printer::format(text_info&)
../../gcc-bug/gcc/pretty-print.cc:1710
0x295c238 pp_format(pretty_printer*, text_info*)
../../gcc-bug/gcc/pretty-print.h:594
0x295c238 diagnostic_context::report_diagnostic(diagnostic_info*)
../../gcc-bug/gcc/diagnostic.cc:1504
0x295c665 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
../../gcc-bug/gcc/diagnostic.cc:1640
0x29718af error(char const*, ...)
../../gcc-bug/gcc/diagnostic-global-context.cc:397
0xd3c9cd push_template_decl(tree_node*, bool)
../../gcc-bug/gcc/cp/pt.cc:6250
0xb88aab start_preparsed_function(tree_node*, tree_node*, int)
../../gcc-bug/gcc/cp/decl.cc:18500
0xb9f946 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../gcc-bug/gcc/cp/decl.cc:18837
0xccbfd7 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-bug/gcc/cp/parser.cc:33569
0xccbfd7 cp_parser_init_declarator
../../gcc-bug/gcc/cp/parser.cc:24051
0xcd40e3 cp_parser_single_declaration
../../gcc-bug/gcc/cp/parser.cc:34112
0xcd433f cp_parser_template_declaration_after_parameters
../../gcc-bug/gcc/cp/parser.cc:33766
0xcd433f cp_parser_explicit_template_declaration
../../gcc-bug/gcc/cp/parser.cc:33940
0xcd4767 cp_parser_template_declaration_after_export
../../gcc-bug/gcc/cp/parser.cc:33959
0xcd4767 cp_parser_template_declaration_after_parameters
../../gcc-bug/gcc/cp/parser.cc:33754
0xcd4767 cp_parser_explicit_template_declaration
../../gcc-bug/gcc/cp/parser.cc:33940
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/ccLr1ffQ.out file, please attach this to
your bugreport.
```

The bug looks similar to PR118060 but the reproducer in that bug report doesn't
fail anymore on GCC trunk.

On Godbolt GCC 15.1 prints the following error message:
```
:16: confused by earlier errors, bailing out
```

[Bug middle-end/119999] [12/13 Regression] explicit infinite goto loop removed causing assert

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.5

--- Comment #1 from Andrew Pinski  ---
I am not 100% sure this is valid code ...
In C++ requires you to have forward progress and this inifite loop is not
foward progress at all:

void f(int * p){ 
l:
assert (p == &a);
if (b)
goto l;
}

Which makes it undefined ...

[Bug debug/78685] -Og generates too many ""s

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

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

--- Comment #32 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:3cf97980aaab6971ae179625a5e1188255dcf925

commit r16-273-g3cf97980aaab6971ae179625a5e1188255dcf925
Author: Richard Biener 
Date:   Mon Apr 28 13:31:16 2025 +0200

debug/78685 - reword -Og documentation

The following rewords the documentation for -Og which over-promises
the ability to debug the generated code.  While -Og enables
var-tracking and thus improves debugging in some areas the experience
is usually worse than -O0 for standard C code.

PR debug/78685
* doc/invoke.texi (-Og): Reword.

[Bug debug/78685] -Og generates too many ""s

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

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

--- Comment #31 from Jakub Jelinek  ---
That is nonsense.
-O0 -fvar-tracking doesn't work and would be substantial amount of work, far
more than artificially adding uses of all vars at the end of their scopes for
-Og.

[Bug debug/78685] -Og generates too many ""s

[Hi-Angel at yandex dot ru via Gcc-bugs]

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

--- Comment #33 from Konstantin Kharlamov  ---
@Richard Biener: thank you for the change! If I may point out though, the new
text still says:

> […]-Og should be the optimization level of choice for the standard
> edit-compile-debug cycle, offering a reasonable blend of optimization, fast
> compilation and debugging experience[…]

which is a problem, because it which is a problem, because it the actual
situation. I know not a single project who uses Og for debugging due to the
"optimized out" issue.

May I suggest to reword this as something like:

> -Og may sometimes be preferred to -O0 during the development when speed is
> important, but otherwise -O0 provides the best debugging experience.

WDYT?

[Bug debug/78685] -Og generates too many ""s

[Hi-Angel at yandex dot ru via Gcc-bugs]

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

--- Comment #34 from Konstantin Kharlamov  ---
> which is a problem, because it which is a problem, because it the actual 
> situation

whoops, sorry, not sure what happened to that part, it's supposed to be "which
is a problem, because it contradicts to the actual situation".

[Bug rtl-optimization/119982] [16 Regression] FAIL: gcc.target/i386/pr109362.c scan-assembler \tmovq\t8\\(%rdi\\), %r by r16-190-g6901d56fea2132

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #2)
> 
> and nothing in the RTL pipeline sees to "fix" this - forwprop or
> now late_combine comes to my mind (RTL combine doesn't work across
> BBs either).

That is because both are very conserative when it comes to volatile mem. See PR
60749 (and others).

[Bug c++/119983] Member function in unnamed type causes internal compiler error in module.

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

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org
   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Nathaniel Shead  ---
Thanks for the report!  As Andrew noted, the ICE is fixed for 14.3 by
r14-10825-g01d3a974fe3474c37cd52b595c29dddafad954dc.

The code is ill-formed, however:

  export module M;
  struct {} instance;

is not legal in a module interface, because of
https://eel.is/c++draft/basic.link#15.2 (the type of the unnamed struct is
TU-local), https://eel.is/c++draft/basic.link#14 (the declaration of the
variable exposes the TU-local type), and https://eel.is/c++draft/basic.link#17
(the variable is not TU-local, so this is ill-formed).

We don't check this in GCC 14 (so 14.3 will accept this code), but for GCC 15
we properly implement https://wg21.link/p1815 and so error in this case:

:2:11: error: 'instance' exposes TU-local entity 'struct'
2 | struct {} instance;
  |   ^~~~
:2:8: note: '' has no name and is not defined within a
class, function, or initializer
2 | struct {} instance;
  |^

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 119983 Summary: Member function in unnamed type causes internal compiler 
error in module.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119983

   What|Removed |Added

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

[Bug c++/119983] Member function in unnamed type causes internal compiler error in module.

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

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

--- Comment #3 from Nathaniel Shead  ---
I will note that making the variable internal linkage will silence GCC 15,
since a TU-local variable itself is not an exposure; this is appropriate if you
only need the variable within that TU.  For example, adjusting your original
testcase, the following sample is valid:

export  module  M;
static struct
{
void aRandomFunc()
{

}
} variableWithNamelessType{};

export void foo() {
variableWithNamelessType.aRandomFunc();
}

[Bug rtl-optimization/119982] [16 Regression] FAIL: gcc.target/i386/pr109362.c scan-assembler \tmovq\t8\\(%rdi\\), %r by r16-190-g6901d56fea2132

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 29 Apr 2025, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119982
> 
> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>See Also||https://gcc.gnu.org/bugzill
>||a/show_bug.cgi?id=60749
> 
> --- Comment #3 from Andrew Pinski  ---
> (In reply to Richard Biener from comment #2)
> > 
> > and nothing in the RTL pipeline sees to "fix" this - forwprop or
> > now late_combine comes to my mind (RTL combine doesn't work across
> > BBs either).
> 
> That is because both are very conserative when it comes to volatile mem. See 
> PR
> 60749 (and others).

So that to me means we'd either WONTFIX the original bugreport and remove
the test or come to senses and allow optimizations to the addressing
mode of volatile mems.

At least GIMPLE (and TER, as can be seen) have no problems with
"optimizing" volatiles - and in this case the "volatile" isn't
even visible, it's a call argument on GIMPLE.

[Bug gcov-profile/118581] auto_profile can't annotate bb with all debug_stmt which assigned value with constant

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:59e853308bd797f91df15fd0fa65a3b5ce2cf4a2

commit r16-274-g59e853308bd797f91df15fd0fa65a3b5ce2cf4a2
Author: hongtao.liu 
Date:   Wed Jan 22 07:44:01 2025 +0100

Annotate empty bb with all debug_stmt with location of phi in the
single_succ.

For an empty BB with all debug_stmt, it will be ignored by
afdo_set_bb_count, but it can be set with count of single successors
PHIs which edge from the BB.

gcc/ChangeLog:

PR gcov-profile/118581
* auto-profile.cc (autofdo_source_profile::get_count_info):
Overload the function with parameter gimple location instead
of stmt.
(afdo_set_bb_count): For !has_annotated BB, Check single
successors PHIs corresponding to the block and use those
count.

[Bug debug/78685] -Og generates too many ""s

[lukas.graetz--- via Gcc-bugs]

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

--- Comment #35 from Lukas Grätz  ---
(In reply to Jakub Jelinek from comment #31)
> That is nonsense.
> -O0 -fvar-tracking doesn't work and would be substantial amount of work, far
> more than artificially adding uses of all vars at the end of their scopes
> for -Og.

I do not understand what you mean, -O0 -fvar-tracking works without a warning
indicating that something went wrong. That said, I am not entirely sure if you
really need that option for -O0. According to your GCC documentation, it might
be needed. If I remember correctly, DWARF should contain the debugging info
also for the prolog/epilog but the base frame is computation is more difficult
there.

I agree with Konstantin Kharlamov about the misleading documentation, I also
observed that -O0 often provides a better debugging experience.