[Bug tree-optimization/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 Sam James changed: What|Removed |Added See Also||https://bugs.gentoo.org/sho ||w_bug.cgi?id=955635 CC||sjames at gcc dot gnu.org --- Comment #3 from Sam James --- The -fno-strict-aliasing (and some of the other options) option as a "hardening" measure is ridiculous and they shouldn't be recommending that, see https://github.com/ossf/wg-best-practices-os-developers/issues/660. Anyway, we actually had a similar report of this from a user who decided to use -fno-strict-aliasing to build glibc: https://bugs.gentoo.org/955635.
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
--- Comment #13 from Jakub Jelinek ---
In the good case,
_Unwind_Find_FDE (pc=0x77dc32cb <_Unwind_Backtrace+59>,
bases=bases@entry=0x7fffe008) at ../../../libgcc/unwind-dw2-btree.h:860
calls _dl_find_object on that pc and it gives
(gdb) p dlfo
$5 = {dlfo_flags = 0, dlfo_map_start = 0x77da, dlfo_map_end =
0x77dcf3c8, dlfo_link_map = 0xc2d0, dlfo_eh_frame = 0x77dc8af4,
__dflo_reserved = {0, 1933,
140737353382200, 140737353867808, 140737488346600, 140737488346596, 0}}
which looks ok because that address is at 0x232cb from start of the library.
In the bad case we get for the same address in libgcc_s loaded at the same base
$7 = {dlfo_flags = 0x0, dlfo_map_start = 0x0, dlfo_map_end = 0x77ffe310,
dlfo_link_map = 0x77ffdda0, dlfo_eh_frame = 0x77ff5c58, __dflo_reserved
= {0x0, 0x78d,
0x77f47938, 0x77fbe220, 0x7fffdde8, 0x7fffdde4, 0x0}}
so it looks like the ld.so entry spans all addresses from 0 to end of the ld.so
mapping (0x77ffe310 matches
77fc6000-77fc7000 r--p 103:03 1853108
/tmp/build2/elf/ld.so
77fc7000-77fef000 r-xp 1000 103:03 1853108
/tmp/build2/elf/ld.so
77fef000-77ffb000 r--p 00029000 103:03 1853108
/tmp/build2/elf/ld.so
77ffb000-77ffd000 r--p 00035000 103:03 1853108
/tmp/build2/elf/ld.so
77ffd000-77ffe000 rw-p 00037000 103:03 1853108
/tmp/build2/elf/ld.so
77ffe000-77fff000 rw-p 00:00 0
).
That is
_dl_rtld_map.l_map_start = (ElfW(Addr)) &__ehdr_start;
_dl_rtld_map.l_map_end = (ElfW(Addr)) _end;
__ehdr_start is for both the good and bad linker:
readelf -Wa build*/elf/ld.so | grep __ehdr_start
354: 0 NOTYPE LOCAL DEFAULT1 __ehdr_start
354: 0 NOTYPE LOCAL DEFAULT1 __ehdr_start
so it just seems that in the bad case the relocation for it hasn't been done.
[Bug rtl-optimization/116389] [15/16 regression] [avr] ICE in extract_constrain_insn for avrtiny and -O2 with ext-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389 --- Comment #11 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:fc0a8eee5b599cb475ba067ed8ee965cec17c447 commit r16-1511-gfc0a8eee5b599cb475ba067ed8ee965cec17c447 Author: Georg-Johann Lay Date: Sat Jun 14 19:57:18 2025 +0200 AVR: Fix PR120423 / PR116389. The problem with PR120423 and PR116389 is that reload might assign an invalid hard register to a paradoxical subreg. For example with the test case from the PR, it assigns (REG:QI 31) to the inner of (subreg:HI (QI) 0) which is valid, but the subreg will be turned into (REG:HI 31) which is invalid and triggers an ICE in postreload. The problem only occurs with the old reload pass. The patch maps the paradoxical subregs to a zero-extends which will be allocated correctly. For the 120423 testcases, the code is the same like with -mlra (which doesn't implement the fix), so the patch doesn't even introduce a performance penalty. The patch is only needed for v15: v14 is not affected, and in v16 reload will be removed. PR rtl-optimization/120423 PR rtl-optimization/116389 gcc/ * config/avr/avr.md [-mno-lra]: Add pre-reload split to transform (left shift of) a paradoxical subreg to a (left shift of) zero-extend. gcc/testsuite/ * gcc.target/avr/torture/pr120423-1.c: New test. * gcc.target/avr/torture/pr120423-2.c: New test. * gcc.target/avr/torture/pr120423-116389.c: New test. (cherry picked from commit 61789b5abec3079d02ee9eaa7468015ab1f6f701)
[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183 Bug 56183 depends on bug 116389, which changed state. Bug 116389 Summary: [15/16 regression] [avr] ICE in extract_constrain_insn for avrtiny and -O2 with ext-dce https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/120423] ICE in avr-gcc extract_constrain_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120423 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |15.2 Resolution|--- |FIXED --- Comment #5 from Georg-Johann Lay --- Worked around in v15.2+
[Bug rtl-optimization/120423] ICE in avr-gcc extract_constrain_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120423 --- Comment #3 from GCC Commits --- The releases/gcc-15 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:61789b5abec3079d02ee9eaa7468015ab1f6f701 commit r15-9837-g61789b5abec3079d02ee9eaa7468015ab1f6f701 Author: Georg-Johann Lay Date: Sat Jun 14 19:57:18 2025 +0200 AVR: Fix PR120423 / PR116389. The problem with PR120423 and PR116389 is that reload might assign an invalid hard register to a paradoxical subreg. For example with the test case from the PR, it assigns (REG:QI 31) to the inner of (subreg:HI (QI) 0) which is valid, but the subreg will be turned into (REG:HI 31) which is invalid and triggers an ICE in postreload. The problem only occurs with the old reload pass. The patch maps the paradoxical subregs to a zero-extends which will be allocated correctly. For the 120423 testcases, the code is the same like with -mlra (which doesn't implement the fix), so the patch doesn't even introduce a performance penalty. The patch is only needed for v15: v14 is not affected, and in v16 reload will be removed. PR rtl-optimization/120423 PR rtl-optimization/116389 gcc/ * config/avr/avr.md [-mno-lra]: Add pre-reload split to transform (left shift of) a paradoxical subreg to a (left shift of) zero-extend. gcc/testsuite/ * gcc.target/avr/torture/pr120423-1.c: New test. * gcc.target/avr/torture/pr120423-2.c: New test. * gcc.target/avr/torture/pr120423-116389.c: New test.
[Bug rtl-optimization/120423] ICE in avr-gcc extract_constrain_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120423 --- Comment #4 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:fc0a8eee5b599cb475ba067ed8ee965cec17c447 commit r16-1511-gfc0a8eee5b599cb475ba067ed8ee965cec17c447 Author: Georg-Johann Lay Date: Sat Jun 14 19:57:18 2025 +0200 AVR: Fix PR120423 / PR116389. The problem with PR120423 and PR116389 is that reload might assign an invalid hard register to a paradoxical subreg. For example with the test case from the PR, it assigns (REG:QI 31) to the inner of (subreg:HI (QI) 0) which is valid, but the subreg will be turned into (REG:HI 31) which is invalid and triggers an ICE in postreload. The problem only occurs with the old reload pass. The patch maps the paradoxical subregs to a zero-extends which will be allocated correctly. For the 120423 testcases, the code is the same like with -mlra (which doesn't implement the fix), so the patch doesn't even introduce a performance penalty. The patch is only needed for v15: v14 is not affected, and in v16 reload will be removed. PR rtl-optimization/120423 PR rtl-optimization/116389 gcc/ * config/avr/avr.md [-mno-lra]: Add pre-reload split to transform (left shift of) a paradoxical subreg to a (left shift of) zero-extend. gcc/testsuite/ * gcc.target/avr/torture/pr120423-1.c: New test. * gcc.target/avr/torture/pr120423-2.c: New test. * gcc.target/avr/torture/pr120423-116389.c: New test. (cherry picked from commit 61789b5abec3079d02ee9eaa7468015ab1f6f701)
[Bug rtl-optimization/116389] [15/16 regression] [avr] ICE in extract_constrain_insn for avrtiny and -O2 with ext-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Georg-Johann Lay --- Worked around in v15.2+
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
--- Comment #15 from Florian Weimer ---
Jakub, thanks for the really helpful analysis!
In glibc, we do additional gymnastics to self-relocate the dynamic linker
earlier, with a compiler barrier, but only for HIDDEN_VAR_NEEDS_DYNAMIC_RELOC
architectures (like MIPS)—not for x86-64. I admit that this is not entirely
correct because GCC can materialize constants that require relocation into
global data. This happens in the Fedora 42 build as well, for the rfv constant
in dl_vdso_vsym in sysdeps/unix/sysv/linux/dl-vdso.h:
const struct r_found_version rfv = { VDSO_NAME, VDSO_HASH, 1, NULL };
/* Search the scope of the vdso map. */
const ElfW (Sym) *ref = &wsym;
lookup_t result = GLRO (dl_lookup_symbol_x) (name, map, &ref,
map->l_local_scope,
&rfv, 0, 0, NULL);
return ref != NULL ? DL_SYMBOL_ADDRESS (result, ref) : NULL;
It just so happens that the first call to dl_vdso_vsym happens after the call
to ELF_DYNAMIC_RELOCATE for ld.so, which is why this works. But the entire
design really assumes that the ELF_DYNAMIC_RELOCATE call is a no-op.
So maybe we are just naïve, and need to treat all architectures as
HIDDEN_VAR_NEEDS_DYNAMIC_RELOC? Or get real, remove the ELF_DYNAMIC_RELOCATE
call for ld.so on !HIDDEN_VAR_NEEDS_DYNAMIC_RELOC architectures because it
should do nothing at all, and add a test case that requires that there are no
dynamic relocations whatsoever. But it looks like the latter would require a
way to request that GCC does not produce global data constants (with
relocations) for initializing local variables.
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 --- Comment #17 from H.J. Lu --- (In reply to Jakub Jelinek from comment #14) > Seems _dl_start_final is in this configuration inlined into _dl_start and > the important difference is (-fstrict-aliasing to -fno-strict-aliasing): > @@ -1206,11 +1207,8 @@ _dl_start: > pushq %rbp > .cfi_def_cfa_offset 16 > .cfi_offset 6, -16 > - leaq__ehdr_start(%rip), %rsi This doesn't need run-time relocation. > leaq_end(%rip), %rax > - movq%rsi, %xmm2 > movq%rax, %xmm3 > - punpcklqdq %xmm3, %xmm2 > movq%rsp, %rbp > .cfi_def_cfa_register 6 > pushq %r15 > @@ -1225,214 +1223,176 @@ _dl_start: > .cfi_offset 12, -48 > .cfi_offset 3, -56 > movq%rdi, -136(%rbp) > + movq.LC31(%rip), %xmm2 > + punpcklqdq %xmm3, %xmm2 > movaps %xmm2, -128(%rbp) > rdtsc > + leaq__ehdr_start(%rip), %rdi > andb$-33, 854+_dl_rtld_map(%rip) > - leaq64+_dl_rtld_map(%rip), %rcx > - movl$1879048191, %r8d > - movl$1879048233, %r9d > + movq%rdi, _dl_rtld_map(%rip) > salq$32, %rdx > - movq%rsi, _dl_rtld_map(%rip) > orq %rdx, %rax > leaq_DYNAMIC(%rip), %rdx > movq%rax, start_time(%rip) > movq_DYNAMIC(%rip), %rax > ... > @@ -6289,9 +6296,13 @@ _rtld_global_ro: > .globl _rtld_local_ro > .hidden _rtld_local_ro > .set_rtld_local_ro,_rtld_global_ro > + .section.data.rel.ro.local > + .align 8 > +.LC31: > + .quad __ehdr_start This requires the run-time relocation. This is another case of PR 103762.
[Bug target/120651] [15/16 Regression] RISC-V: Miscompile at -O3 with -flto since r15-3228-g771256bcb9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120651 Sam James changed: What|Removed |Added Target Milestone|--- |15.2 Keywords||wrong-code
[Bug target/120652] [16 Regression] RISC-V: ICE in require, at machmode.h:323 with rv64gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120652 Sam James changed: What|Removed |Added Target Milestone|--- |16.0 Keywords||ice-on-valid-code
[Bug target/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
--- Comment #18 from H.J. Lu ---
[hjl@gnu-zen4-1 cvise-1]$ cat x.i
typedef long Elf64_Addr;
struct
{
Elf64_Addr l_map_start, l_map_end;
} _dl_rtld_map;
extern int __ehdr_start __attribute__((visibility("hidden")));
extern int _end __attribute__((visibility("hidden")));
void
__attribute___dl_start (void)
{
_dl_rtld_map.l_map_start = (Elf64_Addr)&__ehdr_start;
_dl_rtld_map.l_map_end = (Elf64_Addr)&_end;
}
[hjl@gnu-zen4-1 cvise-1]$ gcc -S -O2 -fPIC x.i
[hjl@gnu-zen4-1 cvise-1]$ cat x.s
.file "x.i"
.text
.p2align 4
.globl __attribute___dl_start
.type __attribute___dl_start, @function
__attribute___dl_start:
.LFB0:
.cfi_startproc
movq.LC0(%rip), %xmm0
leaq_end(%rip), %rax
movq%rax, %xmm1
movq_dl_rtld_map@GOTPCREL(%rip), %rax
punpcklqdq %xmm1, %xmm0
movups %xmm0, (%rax)
ret
.cfi_endproc
.LFE0:
.size __attribute___dl_start, .-__attribute___dl_start
.globl _dl_rtld_map
.bss
.align 16
.type _dl_rtld_map, @object
.size _dl_rtld_map, 16
_dl_rtld_map:
.zero 16
.section.data.rel.ro.local,"aw"
.align 8
.LC0:
.quad __ehdr_start
.hidden __ehdr_start
.hidden _end
.ident "GCC: (GNU) 15.1.1 20250521 (Red Hat 15.1.1-2)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-zen4-1 cvise-1]$ gcc -S -O1 -fPIC x.i
[hjl@gnu-zen4-1 cvise-1]$ cat x.s
.file "x.i"
.text
.globl __attribute___dl_start
.type __attribute___dl_start, @function
__attribute___dl_start:
.LFB0:
.cfi_startproc
movq_dl_rtld_map@GOTPCREL(%rip), %rax
leaq__ehdr_start(%rip), %rdx
movq%rdx, (%rax)
leaq_end(%rip), %rcx
movq%rcx, 8(%rax)
ret
.cfi_endproc
.LFE0:
.size __attribute___dl_start, .-__attribute___dl_start
.globl _dl_rtld_map
.bss
.align 16
.type _dl_rtld_map, @object
.size _dl_rtld_map, 16
_dl_rtld_map:
.zero 16
.hidden _end
.hidden __ehdr_start
.ident "GCC: (GNU) 15.1.1 20250521 (Red Hat 15.1.1-2)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-zen4-1 cvise-1]$
[Bug cobol/120621] COBOL isn't built with STRICT_WARN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120621 James K. Lowden changed: What|Removed |Added Last reconfirmed||2025-06-14 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from James K. Lowden --- fix pending in local repository. Thanks for the pointer.
[Bug fortran/51961] [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51961 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 61639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61639&action=edit Draft patch This patch adjusts the checks for MOLD= and makes gfortran agree with ifx (default options) or additional warnings with -pedantic, mimicking the warnings emitted by NAG.
[Bug fortran/120656] SEGV with a Function Returning a TYPE with ALLOCATABLE Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120656 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-06-14 Keywords||wrong-code --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed when compiling with -O0 or -Og. Works here at -O1 and higher. However, valgrind complains: SIZE(F1) =1 ==29400== Invalid read of size 8 ==29400==at 0x400B28: MAIN__ (pr120656.f90:18) ==29400==by 0x400C24: main (pr120656.f90:19) ==29400== Address 0x4f3ed10 is 8 bytes after a block of size 72 free'd ==29400==at 0x484470B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29400==by 0x400B27: MAIN__ (pr120656.f90:18) ==29400==by 0x400C24: main (pr120656.f90:19) ==29400== Block was alloc'd at ==29400==at 0x48489BC: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==29400==by 0x400AEB: MAIN__ (pr120656.f90:18) ==29400==by 0x400C24: main (pr120656.f90:19) ==29400== SIZE(F2) =1
[Bug c/120657] New: Improve diagnostic for conditional operators that create the invalid type restrict void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120657
Bug ID: 120657
Summary: Improve diagnostic for conditional operators that
create the invalid type restrict void
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: luigighiron at gmail dot com
Target Milestone: ---
Here are two programs that both incorrectly use a conditional operator, and
their error messages generated by GCC ( is the name of the file on
godbolt).
Program 1:
int main(void){
void*p=0;
int*restrict*q=0;
typedef typeof(1?p:q)T;
}
Error 1:
:4:5: error: invalid use of 'restrict'
4 | typedef typeof(1?p:q)T;
| ^~~
Program 2:
int main(void){
float*p=0;
int*restrict*q=0;
typedef typeof(1?p:q)T;
}
Error 2:
:4:23: error: pointer type mismatch in conditional expression
[-Wincompatible-pointer-types]
4 | typedef typeof(1?p:q)T;
| ^
:4:22: note: first expression has type 'float *'
4 | typedef typeof(1?p:q)T;
| ^
:4:24: note: second expression has type 'int * restrict*'
4 | typedef typeof(1?p:q)T;
|^
In error 2 the colon of the conditional expression is pointed to, and the type
of the operands are pointed out to help clarify the issue. However, in error 1
it just says restrict is used incorrectly and points to the first token on the
same line as the closing parenthesis. I think it is worth improving the error
message of program 1 to indicate that the conditional expression is causing the
error.
[Bug tree-optimization/109045] assume attribute does not always optimize std::optional cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109045 --- Comment #4 from Thiago Macieira --- Even then those are function calls. But at the state of art of both compilers, we can't assume on results of calls.
[Bug target/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
H.J. Lu changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #20 from H.J. Lu ---
(In reply to Sergio Durigan Junior from comment #0)
> Hi,
>
> This is an interesting bug which took me quite some time to (partially)
> understand. I decided to file this upstream report to:
>
> - See if an upstream developer could help me fully understand what's going
> one, and
> - Get a patch backported to GCC 14 to fix the issue.
>
> It all started when we noticed that compiling a glibc using the following
> hardening flags (from the OpenSSF project) would lead to an abortion in
> certain scenarios:
>
>
> *self_spec:
> + %{!O:%{!O1:%{!O2:%{!O3:%{!O0:%{!Os:%{!0fast:%{!0g:%{!0z:-O2}
> -fhardened -Wno-error=hardened -Wno-hardened
> %{!fdelete-null-pointer-checks:-fno-delete-null-pointer-checks}
> -fno-strict-overflow -fno-strict-aliasing
> %{!fomit-frame-pointer:-fno-omit-frame-pointer} -mno-omit-leaf-frame-pointer
>
> *link:
> + --as-needed -O1 --sort-common -z noexecstack -z relro -z now
>
>
> It is important to notice that:
>
> - The bug only happens when using a glibc compiled with the "-z now"
> hardening flag. If the flag is removed, then the abort doesn't occur.
> - The bug only happens when using a glibc compiled with GCC 14.x (14.3
> included).
Please provide the output of
# readelf -rW elf/rtld.os | grep __ehdr_start
on the bad glibc build. Is there
00080001 R_X86_64_64
__ehdr_start + 0
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
--- Comment #14 from Jakub Jelinek ---
Seems _dl_start_final is in this configuration inlined into _dl_start and the
important difference is (-fstrict-aliasing to -fno-strict-aliasing):
@@ -1206,11 +1207,8 @@ _dl_start:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
- leaq__ehdr_start(%rip), %rsi
leaq_end(%rip), %rax
- movq%rsi, %xmm2
movq%rax, %xmm3
- punpcklqdq %xmm3, %xmm2
movq%rsp, %rbp
.cfi_def_cfa_register 6
pushq %r15
@@ -1225,214 +1223,176 @@ _dl_start:
.cfi_offset 12, -48
.cfi_offset 3, -56
movq%rdi, -136(%rbp)
+ movq.LC31(%rip), %xmm2
+ punpcklqdq %xmm3, %xmm2
movaps %xmm2, -128(%rbp)
rdtsc
+ leaq__ehdr_start(%rip), %rdi
andb$-33, 854+_dl_rtld_map(%rip)
- leaq64+_dl_rtld_map(%rip), %rcx
- movl$1879048191, %r8d
- movl$1879048233, %r9d
+ movq%rdi, _dl_rtld_map(%rip)
salq$32, %rdx
- movq%rsi, _dl_rtld_map(%rip)
orq %rdx, %rax
leaq_DYNAMIC(%rip), %rdx
movq%rax, start_time(%rip)
movq_DYNAMIC(%rip), %rax
...
@@ -6289,9 +6296,13 @@ _rtld_global_ro:
.globl _rtld_local_ro
.hidden _rtld_local_ro
.set_rtld_local_ro,_rtld_global_ro
+ .section.data.rel.ro.local
+ .align 8
+.LC31:
+ .quad __ehdr_start
.section.rodata.cst16,"aM",@progbits,16
.align 16
-.LC74:
+.LC75:
.quad -1
.quad 0
.hidden __rtld_libc_freeres
The compiler has decided to vectorize the __ehdr_start and _end stores in both
cases, optimized dump has similar code like:
_359 = (long unsigned int) &_end;
_358 = (long unsigned int) &__ehdr_start;
_357 = {_358, _359};
...
MEM [(long unsigned int *)&_dl_rtld_map + 912B]
= _357;
Before RA we have in both cases something like
(insn 15 3 1129 2 (set (reg/f:DI 253)
(symbol_ref:DI ("__ehdr_start") [flags 0x42] )) 84 {*movdi_internal}
(expr_list:REG_EQUIV (symbol_ref:DI ("__ehdr_start") [flags 0x42]
)
(nil)))
(insn 1129 15 16 2 (set (reg/f:DI 252)
(symbol_ref:DI ("_end") [flags 0x42] ))
84 {*movdi_internal}
(expr_list:REG_EQUIV (symbol_ref:DI ("_end") [flags 0x42] )
(nil)))
(insn 16 1129 18 2 (set (reg:V2DI 235 [ _357 ])
(vec_concat:V2DI (reg/f:DI 253)
(reg/f:DI 252))) 7525 {vec_concatv2di}
(expr_list:REG_DEAD (reg/f:DI 252)
(expr_list:REG_EQUIV (vec_concat:V2DI (symbol_ref:DI ("__ehdr_start")
[flags 0x42] )
(symbol_ref:DI ("_end") [flags 0x42] ))
(nil
i.e. set one pseudo to __ehdr_start, another to _end and do vec_concat on that.
But in the -fno-strict-aliasing case RA decides to spill __ehdr_start into
memory and
load from memory:
(insn 1102 13 1107 2 (set (reg/f:DI 0 ax [258])
(symbol_ref:DI ("_end") [flags 0x42] ))
84 {*movdi_internal}
(expr_list:REG_EQUIV (symbol_ref:DI ("_end") [flags 0x42] )
(nil)))
(insn 1107 1102 1109 2 (set (reg:DI 22 xmm2 [orig:243 _359 ] [243])
(mem/u/c:DI (symbol_ref/u:DI ("*.LC31") [flags 0x2]) [0 S8 A64])) 84
{*movdi_internal}
(nil))
(insn 1109 1107 14 2 (set (reg/f:DI 23 xmm3 [258])
(reg/f:DI 0 ax [258])) 84 {*movdi_internal}
(nil))
(insn 14 1109 1108 2 (set (reg:V2DI 22 xmm2 [orig:243 _359 ] [243])
(vec_concat:V2DI (reg:DI 22 xmm2 [orig:243 _359 ] [243])
(reg/f:DI 23 xmm3 [258]))) 7525 {vec_concatv2di}
(expr_list:REG_EQUIV (vec_concat:V2DI (symbol_ref:DI ("__ehdr_start")
[flags 0x42] )
(symbol_ref:DI ("_end") [flags 0x42] ))
(nil)))
while in the -fstrict-aliasing case it doesn't:
(insn 15 3 1129 2 (set (reg/f:DI 4 si [253])
(symbol_ref:DI ("__ehdr_start") [flags 0x42] )) 84 {*movdi_internal}
(expr_list:REG_EQUIV (symbol_ref:DI ("__ehdr_start") [flags 0x42]
)
(nil)))
(insn 1129 15 1134 2 (set (reg/f:DI 0 ax [252])
(symbol_ref:DI ("_end") [flags 0x42] ))
84 {*movdi_internal}
(expr_list:REG_EQUIV (symbol_ref:DI ("_end") [flags 0x42] )
(nil)))
(insn 1134 1129 1136 2 (set (reg:DI 22 xmm2 [orig:235 _357 ] [235])
(reg/f:DI 4 si [253])) 84 {*movdi_internal}
(nil))
(insn 1136 1134 16 2 (set (reg/f:DI 23 xmm3 [252])
(reg/f:DI 0 ax [252])) 84 {*movdi_internal}
(nil))
(insn 16 1136 1135 2 (set (reg:V2DI 22 xmm2 [orig:235 _357 ] [235])
(vec_concat:V2DI (reg:DI 22 xmm2 [orig:235 _357 ] [235])
(reg/f:DI 23 xmm3 [252]))) 7525 {vec_concatv2di}
(expr_list:REG_EQUIV (vec_concat:V2DI (symbol_ref:DI ("__ehdr_start")
[flags 0x42] )
(symbol_ref:DI ("_end") [flags 0x42] ))
(nil)))
I don't really see anything wrong here on the GCC side.
Perhaps rtld.c should be compiled with -fno-tree-vectorize -fn
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 --- Comment #16 from Sergio Durigan Junior --- Thank you very much for the detailed investigation; much appreciated. I'm not sure if it's still needed, but to reply to Jakub's request, here's how glibc is being built: https://github.com/wolfi-dev/os/blob/main/glibc.yaml I can obtain the build logs if needed; they're not readily accessible unfortunately. The compiler flags are the ones I listed in the description, coming directly from OpenSSF. The recipe above currently disables the hardening flags entirely (by setting GCC_SPEC_FILE to /dev/null, on line 52), but I obviously reenabled them for my tests. Now, it's very interesting that -fno-strict-aliasing can cause such mess. As I said, in my tests it appeared to be "-z now". That Gentoo bug seems to be exactly the same thing as I'm reporting here. I'll run some tests removing -fno-strict-aliasing (but keeping "-z now") and see if it makes a difference.
[Bug target/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 --- Comment #19 from H.J. Lu --- I opened a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33088 and attached a patch: https://sourceware.org/bugzilla/attachment.cgi?id=16138
[Bug rtl-optimization/116389] [15/16 regression] [avr] ICE in extract_constrain_insn for avrtiny and -O2 with ext-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116389 --- Comment #10 from GCC Commits --- The releases/gcc-15 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:61789b5abec3079d02ee9eaa7468015ab1f6f701 commit r15-9837-g61789b5abec3079d02ee9eaa7468015ab1f6f701 Author: Georg-Johann Lay Date: Sat Jun 14 19:57:18 2025 +0200 AVR: Fix PR120423 / PR116389. The problem with PR120423 and PR116389 is that reload might assign an invalid hard register to a paradoxical subreg. For example with the test case from the PR, it assigns (REG:QI 31) to the inner of (subreg:HI (QI) 0) which is valid, but the subreg will be turned into (REG:HI 31) which is invalid and triggers an ICE in postreload. The problem only occurs with the old reload pass. The patch maps the paradoxical subregs to a zero-extends which will be allocated correctly. For the 120423 testcases, the code is the same like with -mlra (which doesn't implement the fix), so the patch doesn't even introduce a performance penalty. The patch is only needed for v15: v14 is not affected, and in v16 reload will be removed. PR rtl-optimization/120423 PR rtl-optimization/116389 gcc/ * config/avr/avr.md [-mno-lra]: Add pre-reload split to transform (left shift of) a paradoxical subreg to a (left shift of) zero-extend. gcc/testsuite/ * gcc.target/avr/torture/pr120423-1.c: New test. * gcc.target/avr/torture/pr120423-2.c: New test. * gcc.target/avr/torture/pr120423-116389.c: New test.
[Bug c++/120655] New: c++17 CTAD, alias template in a constructor render a non-deducible context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120655
Bug ID: 120655
Summary: c++17 CTAD, alias template in a constructor render a
non-deducible context
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jack.cui2 at foxmail dot com
Target Milestone: ---
Below code can not compile while clang can:
template
struct B
{
template
using TA = T;
template
B(U, TA); // #1
};
int main()
{
B b{(int*)0, (char*)0};
return 0;
}
According to https://en.cppreference.com/w/cpp/language/ctad.html
Code should compile.
Using built-in specs.
COLLECT_GCC=gcc
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.3.0-6ubuntu2~24.04' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace
--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-13-fG75Ri/gcc-13-13.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-fG75Ri/gcc-13-13.3.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.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04)
[Bug fortran/120656] New: SEGV with a Function Returning a TYPE with ALLOCATABLE Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120656 Bug ID: 120656 Summary: SEGV with a Function Returning a TYPE with ALLOCATABLE Component Product: gcc Version: 15.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gilbert.scott.99 at googlemail dot com Target Milestone: --- $ cat test.f95 PROGRAM TEST IMPLICIT NONE TYPE :: FOO INTEGER :: I INTEGER, ALLOCATABLE :: N(:) END TYPE FOO TYPE(FOO), ALLOCATABLE :: F1(:) TYPE(FOO), ALLOCATABLE :: F2(:) TYPE(FOO) :: FX ALLOCATE ( F1(0) ) ALLOCATE ( F2(0) ) FX = FOO_NEW(1) F1 = [F1,FX] PRINT *, 'SIZE(F1) = ',SIZE(F1) F2 = [F2,FOO_NEW(2)] PRINT *, 'SIZE(F2) = ',SIZE(F2) CONTAINS FUNCTION FOO_NEW(I) TYPE(FOO) :: FOO_NEW INTEGER, INTENT(IN) :: I FOO_NEW%I = I END FUNCTION FOO_NEW END PROGRAM TEST $ gfortran --version GNU Fortran (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2) $ gfortran -std=2003 -Wall -g -o test test.f95 $ ./test SIZE(F1) =1 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7fea2ac09055 in ??? #1 0x7fea2ac08045 in ??? #2 0x7fea2a939c2f in ??? #3 0x7fea2a9a24c4 in ??? #4 0x401fb1 in test at ./test.f95:19 #5 0x4020c6 in main at ./test.f95:20 Segmentation fault (core dumped) -- The problem is on this line: F2 = [F2,FOO_NEW(2)] There is no problem if the ALLOCATABLE component of type FOO is removed.
[Bug c++/119705] Massive memory use when building Flang (10GB+)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119705 --- Comment #10 from Michał Górny --- I've used the original command, i.e.: /usr/bin/c++ -DFLANG_INCLUDE_TESTS=1 -D_DEBUG -D_GLIBCXX_ASSERTIONS -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/mgorny/git/llvm-project/flang/build/lib/Lower -I/home/mgorny/git/llvm-project/flang/lib/Lower -I/home/mgorny/git/llvm-project/flang/include -I/home/mgorny/git/llvm-project/flang/build/include -isystem /usr/lib/llvm/21/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-nonnull -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Wno-deprecated-copy -Wno-ctad-maybe-unsupported -fno-strict-aliasing -fno-semantic-interposition -std=c++17 -D_GNU_SOURCE -D_DEBUG -D_GLIBCXX_ASSERTIONS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -UNDEBUG -MD -MT lib/Lower/CMakeFiles/FortranLower.dir/OpenMP/DataSharingProcessor.cpp.o -MF lib/Lower/CMakeFiles/FortranLower.dir/OpenMP/DataSharingProcessor.cpp.o.d -o lib/Lower/CMakeFiles/FortranLower.dir/OpenMP/DataSharingProcessor.cpp.o -c /home/mgorny/git/llvm-project/flang/lib/Lower/OpenMP/DataSharingProcessor.cpp on top of 23d0c7348aacdfcb145a69e533a14131bae830cc (I had this version built). 'time -v' yields maximum RSS of: GCC: 7085380 KiB GCC -fsyntax-only: 5192768 KiB Clang: 4064756 KiB Clang -fsyntax-only: 3176188 KiB
[Bug c++/119705] Massive memory use when building Flang (10GB+)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119705 --- Comment #11 from Michał Górny --- Ah, sorry, forgot to mention versions: gcc (Gentoo 14.3.0 p8) 14.3.0 clang version 21.0.0git23d0c734
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 --- Comment #8 from Sam James --- Created attachment 61638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61638&action=edit build.sh
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
--- Comment #9 from Sam James ---
optimize("no-strict-aliasing") on _dl_start_final is enough to break it.
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653
Sam James changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #10 from Sam James ---
(In reply to Sam James from comment #9)
> optimize("no-strict-aliasing") on _dl_start_final is enough to break it.
│ Relocation section '.rela.data.rel.ro.local' at offset 0xe408 contains 1
entry:
│ Offset Info Type Symbol's Value
Symbol's Name + Addend
│ - 00090001 R_X86_64_64
.rodata.str1.1 + 4c4
│ + 00c10001 R_X86_64_64
__ehdr_start + 0
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2025-06-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #11 from Eric Botcazou --- FWIW the *self_spec line contains typos (0fast, 0g, 0z).
[Bug target/120424] [arm] -fnon-call-exceptions -fstack-clash-protection triggers lra-eliminations bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120424 --- Comment #9 from Georg-Johann Lay --- (In reply to Sam James from comment #8) > See > https://inbox.sourceware.org/gcc-patches/ormsalbaic@lxoliva.fsfla.org/. Thanks for the pointer and sorry for the noise. I missed that it's 2 patches, and that the 2nd one isn't upstream yet.
[Bug target/120424] [arm] -fnon-call-exceptions -fstack-clash-protection triggers lra-eliminations bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120424 --- Comment #7 from Georg-Johann Lay --- This patch turns the test cases for gcc.target/avr/torture/pr118591-1.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591#c4 into ICEs: $ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim avr-torture.exp=pr118591-1.c" ... FAIL: gcc.target/avr/torture/pr118591-1.c -O1 (internal compiler error: in update_reg_eliminate, at lra-eliminations.cc:1200) FAIL: gcc.target/avr/torture/pr118591-1.c -O2 (internal compiler error: in update_reg_eliminate, at lra-eliminations.cc:1200) FAIL: gcc.target/avr/torture/pr118591-1.c -Os -flto (internal compiler error: in update_reg_eliminate, at lra-eliminations.cc:1200) FAIL: gcc.target/avr/torture/pr118591-1.c -O2 -mcall-prologues (internal compiler error: in update_reg_eliminate, at lra-eliminations.cc:1200) ...
[Bug target/120424] [arm] -fnon-call-exceptions -fstack-clash-protection triggers lra-eliminations bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120424 --- Comment #8 from Sam James --- (In reply to Georg-Johann Lay from comment #7) > This patch turns the test cases for > > gcc.target/avr/torture/pr118591-1.c > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591#c4 > > into ICEs: > See https://inbox.sourceware.org/gcc-patches/ormsalbaic@lxoliva.fsfla.org/.
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 --- Comment #5 from Sam James --- Created attachment 61636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61636&action=edit rtld.i.xz Building elf/rtld.o with -fno-strict-aliasing breaks it. Attached rtld.i.xz. It's built with: ``` gcc rtld.c -c -std=gnu11 -fgnu89-inline -O2 -Wall -Wwrite-strings -Wundef -Wimplicit-fallthrough -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common -U_FORTIFY_SOURCE -Wstrict-prototypes -Wold-style-definition -fmath-errno -fPIC -fno-stack-protector -DSTACK_PROTECTOR_LEVEL=0 -mno-mmx -fno-tree-loop-distribute-patterns '-DSYSCONFDIR="/etc"' -ftls-model=initial-exec -I../include -I/tmp/build-mangled/elf -I/tmp/build-mangled -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64/include -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/x86/nptl -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86/include -I../sysdeps/x86 -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -D_LIBC_REENTRANT -include /tmp/build-mangled/libc-modules.h -DMODULE_NAME=rtld -include ../include/libc-symbols.h -DPIC -DSHARED -DTOP_NAMESPACE=glibc -o /tmp/build-mangled/elf/rtld.os -MD -MP -MF /tmp/build-mangled/elf/rtld.os.dt -MT /tmp/build-mangled/elf/rtld.os -save-temps ``` Adding -fno-strict-aliasing in there and using a small script to relink and build the tests makes it fail.
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 --- Comment #6 from Sam James --- Created attachment 61637 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61637&action=edit rtld-unwind.tar.xz (tarball containing good/bad rtld.os)
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 --- Comment #7 from Sam James --- The diff between the two is a bit noisy and the layout is a little different. Dunno if it's interesting but in the bad object, __ehdr_start appears in .rela.data.rel.ro.local. ``` │ -Relocation section '.rela.data.rel.ro.local' at offset 0xe408 contains 1 entry: │ +Relocation section '.rela.data.rel.ro.local' at offset 0xe668 contains 2 entries: │ Offset Info Type Symbol's Value Symbol's Name + Addend │ 00090001 R_X86_64_64 .rodata.str1.1 + 4c4 │ +0018 00c10001 R_X86_64_64 __ehdr_start + 0 ```
[Bug c/120654] New: Crash at -O3: during GIMPLE pass: ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120654
Bug ID: 120654
Summary: Crash at -O3: during GIMPLE pass: ivopts
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yunboni at smail dot nju.edu.cn
Target Milestone: ---
This code crashes at -O3:
```c
int a, c, e, f, h, j;
long g, k;
void *malloc(long);
void free(void *);
int b(int m) {
if (m || a)
return 1;
return 0.0f;
}
int d(int m, int p2) { return b(m) + m + (1 + p2 + p2); }
int i() {
long l[] = {2, 9, 7, 8, g, g, 9, 0, 2, g};
e = l[c] << 6;
}
void n() {
long o;
int *p = malloc(sizeof(int));
k = 1 % j;
for (; i() + f + h; o++)
if (p[d(j + 6, (int)k + 1992695866) + h + f + j + (int)k - 1 + o])
free(p);
}
void main() {}
```
Compiler Explorer: https://godbolt.org/z/9bs5x6oEc
Bisected to
https://github.com/gcc-mirror/gcc/commit/5d88932657de239a941ad84ef0996a906ecd8fe9
Crash:
```
during GIMPLE pass: ivopts
: In function 'n':
:15:6: internal compiler error: in type, at value-range.h:984
15 | void n() {
| ^
0x25099e5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x252b176 internal_error(char const*, ...)
???:0
0x9f8608 fancy_abort(char const*, int, char const*)
???:0
0x23b832d split_constant_offset(tree_node*, tree_node**, tree_node**)
???:0
0x133e7f3 tree_ssa_iv_optimize()
???:0
```
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 Sam James changed: What|Removed |Added CC||fw at gcc dot gnu.org Component|tree-optimization |libgcc Keywords||wrong-code --- Comment #4 from Sam James --- I can reproduce in a vanilla fedora:41 container (=> no spec or default patching; should really consider that on our end too) with just build deps installed, then with the glibc-2.41 tarball: ``` $ mkdir /tmp/build && cd /tmp/build $ /tmp/glibc-2.41/configure --prefix=/usr $ make -j$(nproc) -l$(nproc) $ make -j$(nproc) -l$(nproc) check [...] === Summary of results === 5 FAIL 6008 PASS 122 UNSUPPORTED 16 XFAIL 4 XPASS ``` Those are harmless and related to the container. Then: ``` $ mkdir /tmp/build-mangled && cd /tmp/build-mangled $ /tmp/glibc-2.41/configure --prefix=/usr CFLAGS="-O2 -fno-strict-aliasing" $ make -j$(nproc) -l$(nproc) $ make -j$(nproc) -l$(nproc) check [...] === Summary of results === 130 FAIL 5883 PASS 122 UNSUPPORTED 16 XFAIL 4 XPASS $ grep ^FAIL tests.sum | grep back FAIL: debug/backtrace-tst FAIL: debug/tst-backtrace2 FAIL: debug/tst-backtrace3 FAIL: debug/tst-backtrace4 FAIL: debug/tst-backtrace5 FAIL: debug/tst-backtrace6 FAIL: nptl/tst-backtrace1 ```
[Bug tree-optimization/109045] assume attribute does not always optimize std::optional cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109045 Thiago Macieira changed: What|Removed |Added CC||thiago at kde dot org --- Comment #2 from Thiago Macieira --- GCC doesn't print anything and doesn't take the assumption into account, but Clang prints: warning: assumption is ignored because it contains (potential) side-effects [-Wassume] 8 | [[assume(!r || *r > 0)]]; | ~^~~
[Bug tree-optimization/109045] assume attribute does not always optimize std::optional cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109045 --- Comment #3 from Andrew Pinski --- (In reply to Thiago Macieira from comment #2) > GCC doesn't print anything and doesn't take the assumption into account, but > Clang prints: > > warning: assumption is ignored because it contains (potential) side-effects > [-Wassume] > 8 | [[assume(!r || *r > 0)]]; > | ~^~~ I do think this could be done to: [[assume(!r)]]; [[assume(*r > 0)]]; So at least part of the assume could be useful and then maybe ipa sra/cp could do something.
[Bug libgcc/120653] Hardened glibc (-z now) compiled with GCC 14.3 will crash when unwinding stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120653 --- Comment #12 from Jakub Jelinek --- Reproduced. It is actually _Unwind_Find_FDE not finding context->ra from libgcc_s.so.1 in the bad ld.so case and finding it in the correct case.
