[Bug middle-end/119537] assume with statement expression and ("non-local") label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119537
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=51088
--- Comment #4 from Andrew Pinski ---
(In reply to Sam James from comment #2)
> Clang crashes on this variant from the thread too:
> ```
> #include
>
> int main() {
> goto *&&x;
> typeof(({x: puts("hi");}) ) nope;
> }
> ```
[Bug gcov-profile/119535] v2: musttail vs -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119535
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-03-29
Summary|[15 regression] Firefox |v2: musttail vs
|fails to build |-fprofile-generate
|(SkRasterPipeline_opts.h:16 |
|03:31: error: cannot|
|tail-call: other reasons) |
Ever confirmed|0 |1
--- Comment #5 from Andrew Pinski ---
Reduced testcase:
```
void b(void);
void d(void) {
b();
b();
[[clang::musttail]] return b();
}
```
[Bug c++/94794] coroutines: Support is needed for symmetric transter on targets without arbitrary indirect tail-calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94794 --- Comment #2 from Andrew Pinski --- >the existing "ok for sib call" is not usable in the FE. The existing ok for sib call is not all of the reasons why a tail call might fail during code generation either ...
[Bug target/119539] [15 Regression] FAIL: gcc.target/i386/apx-nf.c scan-assembler-times {nf} rol 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119539 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug c++/94794] coroutines: Support is needed for symmetric transter on targets without arbitrary indirect tail-calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94794 --- Comment #3 from Andrew Pinski --- I wonder if this could be described as a thunk.
[Bug middle-end/119541] New: [15 Regression] asan: dynamic-stack-buffer-overflow in modify_call_for_omp_dispatch at gimplify.cc:3976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119541 Bug ID: 119541 Summary: [15 Regression] asan: dynamic-stack-buffer-overflow in modify_call_for_omp_dispatch at gimplify.cc:3976 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org CC: sandra at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu If you compile the c-c++-common/gomp/dispatch-11.c gcc testsuite testcase using -fopenmp with an AddressSanitizer-instrumented gcc, you get this: ==2494359==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7fff36429498 at pc 0x01a8feac bp 0x7fff36429440 sp 0x7fff36429438 WRITE of size 8 at 0x7fff36429498 thread T0 #0 0x01a8feab in modify_call_for_omp_dispatch /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:3976 #1 0x01b0371c in expand_variant_call_expr /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:4400 #2 0x01b0371c in gimplify_variant_call_expr /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:4502 #3 0x01b0371c in gimplify_call_expr /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:4707 #4 0x01ab13d5 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:19439 #5 0x01aba9dd in gimplify_stmt(tree_node**, gimple**) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:8436 #6 0x01abaaa8 in gimplify_and_add(tree_node*, gimple**) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:547 #7 0x01afded9 in gimplify_omp_dispatch /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:18928 #8 0x01ab005a in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:20142 #9 0x01aba9dd in gimplify_stmt(tree_node**, gimple**) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:8436 #10 0x01aaff7b in gimplify_statement_list /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:2285 #11 0x01aaff7b in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:19921 #12 0x01aba9dd in gimplify_stmt(tree_node**, gimple**) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:8436 #13 0x01abbec3 in gimplify_bind_expr /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:1680 #14 0x01ab1031 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:19671 #15 0x01aba9dd in gimplify_stmt(tree_node**, gimple**) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:8436 #16 0x01ac039c in gimplify_body(tree_node*, bool) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:20773 #17 0x01ac100b in gimplify_function_tree(tree_node*) /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:20982 #18 0x0148939f in cgraph_node::analyze() /home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:689 #19 0x01490f01 in analyze_functions /home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:1265 #20 0x01494100 in symbol_table::finalize_compilation_unit() /home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:2574 #21 0x02594901 in compile_file /home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:479 #22 0x0084daca in do_compile /home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2208 #23 0x0084daca in toplev::main(int, char**) /home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2371 #24 0x0085907d in main /home/worker/buildworker/tiber-gcc-asan/build/gcc/main.cc:39 #25 0x7f198922b12d in __libc_start_call_main (/lib64/libc.so.6+0x2b12d) (BuildId: 4e306825df357f9b661479a3f9d24a8dbf960c1f) #26 0x7f198922b1f8 in __libc_start_main_impl (/lib64/libc.so.6+0x2b1f8) (BuildId: 4e306825df357f9b661479a3f9d24a8dbf960c1f) #27 0x0085ab74 in _start ../sysdeps/x86_64/start.S:115 Address 0x7fff36429498 is located in stack of thread T0 SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow /home/worker/buildworker/tiber-gcc-asan/build/gcc/gimplify.cc:3976 in modify_call_for_omp_dispatch Shadow bytes around the buggy address: 0x7fff36429200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7fff36429280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7fff36429300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7fff36429380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550
--- Comment #27 from GCC Commits ---
The releases/gcc-14 branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:d54c8ebda8674fbed85e2a3c4f141ffe9fa7f8a4
commit r14-11475-gd54c8ebda8674fbed85e2a3c4f141ffe9fa7f8a4
Author: Denis Chertykov
Date: Thu Oct 17 11:12:38 2024 +0400
Reuse scratch registers generated by LRA
Test file: udivmoddi.c
problem insn: 484
Before LRA pass we have:
(insn 484 483 485 72 (parallel [
(set (reg/v:SI 143 [ __q1 ])
(plus:SI (reg/v:SI 143 [ __q1 ])
(const_int -2 [0xfffe])))
(clobber (scratch:QI))
]) "udivmoddi.c":163:405 discrim 5 186 {addsi3}
(nil))
LRA substitute all scratches with new pseudos, so we have:
(insn 484 483 485 72 (parallel [
(set (reg/v:SI 143 [ __q1 ])
(plus:SI (reg/v:SI 143 [ __q1 ])
(const_int -2 [0xfffe])))
(clobber (reg:QI 619))
]) "/mnt/d/avr-lra/udivmoddi.c":163:405 discrim 5 186 {addsi3}
(expr_list:REG_UNUSED (reg:QI 619)
(nil)))
Pseudo 619 is a special scratch register generated by LRA which is marked
in `scratch_bitmap' and can be tested by call `ira_former_scratch_p(regno)'.
In dump file (udivmoddi.c.317r.reload) we have:
Creating newreg=619
Removing SCRATCH to p619 in insn #484 (nop 3)
rescanning insn with uid = 484.
After that LRA tries to spill (reg:QI 619)
It's a bug because (reg:QI 619) is an output scratch register which is
already something like spill register.
Fragment from udivmoddi.c.317r.reload:
Choosing alt 2 in insn 484: (0) r (1) 0 (2) nYnn (3) &d {addsi3}
Creating newreg=728 from oldreg=619, assigning class LD_REGS to r728
IMHO: the bug is in lra-constraints.cc in function `get_reload_reg'
fragment of `get_reload_reg':
if (type == OP_OUT)
{
/* Output reload registers tend to start out with a conservative
choice of register class. Usually this is ALL_REGS, although
a target might narrow it (for performance reasons) through
targetm.preferred_reload_class. It's therefore quite common
for a reload instruction to require a more restrictive class
than the class that was originally assigned to the reload
register.
In these situations, it's more efficient to refine the choice
of register class rather than create a second reload register.
This also helps to avoid cycling for registers that are only
used by reload instructions. */
if (REG_P (original)
&& (int) REGNO (original) >= new_regno_start
&& INSN_UID (curr_insn) >= new_insn_uid_start
__^^
&& in_class_p (original, rclass, &new_class, true))
{
unsigned int regno = REGNO (original);
if (lra_dump_file != NULL)
{
fprintf (lra_dump_file, " Reuse r%d for output ", regno);
dump_value_slim (lra_dump_file, original, 1);
}
This condition incorrectly limits register reuse to ONLY newly generated
instructions.
i.e. LRA can reuse registers only from insns generated by himself.
IMHO:It's wrong.
Scratch registers generated by LRA also have to be reused.
The patch is very simple.
On x86_64, it bootstraps+regtests fine.
gcc/
PR target/116550
PR target/119340
* lra-constraints.cc (get_reload_reg): Reuse scratch registers
generated by LRA.
(cherry picked from commit e7393cbb5f2cae50b42713e71984064073aa378a)
[Bug target/119340] [14 regression] ICE when building gegl-0.4.52 on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Xi Ruoyao --- Fixed by backporting r15-4406.
[Bug cobol/119521] gcc-cobol generated programs with memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119521 --- Comment #3 from Simon Sobisch --- Note: some people will argue that the program should only abort, because/when exception checking is on. At least if it is, libgcobol needs to save the location, statement, file and exception that happened (for later query with related intrinsic, if it isn't enabled then internally the io status, which should be part of the internal file structure, is enough). Maybe the exception parts effectively do a malloc instead of realloc (you'll possibly memcpy if already allocated, of course)?
[Bug c/119526] standard attributes should be preserved in redeclarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119526 uecker at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94171 --- Comment #1 from uecker at gcc dot gnu.org --- .
[Bug cobol/119521] gcc-cobol generated programs with memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119521 --- Comment #4 from Simon Sobisch --- Am 28. März 2025 15:40:49 GMT-12:00 schrieb "rdubner at gcc dot gnu.org" : >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119521 > >--- Comment #2 from Robert Dubner --- >Additional: The leaking memory is because exception checking is turned on. >Still looking... > Note: one could argue that the program should only abort because/when exception checking is on. At least if it is, libgcobol needs to save the location, statement, file and exception that happened (for later query with related intrinsic, if it isn't enabled then internally the io status, which should be part of the internal file structure, is enough). Maybe the exception parts effectively do a malloc instead of realloc (you'll possibly memcpy if already allocated, of course)?
[Bug c++/118961] ICE g++ modules with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118961 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |15.0 Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Nathaniel Shead --- Fixed for GCC 15, thanks for the report! I'm not currently planning on backporting this, it relies on a few other patches for GCC15 that reworked how explicit instantiations were handled. I imagine there may well be other issues with LTO given it's not been particularly well tested yet.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 118961, which changed state. Bug 118961 Summary: ICE g++ modules with LTO https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118961 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/119527] New: [modules] Internal linkage virtual key function of template in header unit is not emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119527
Bug ID: 119527
Summary: [modules] Internal linkage virtual key function of
template in header unit is not emitted
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nshead at gcc dot gnu.org
Blocks: 103524
Target Milestone: ---
Consider:
// header.hpp
namespace {
template struct S {
virtual void key() {}
};
S s;
}
// main.cpp
import "header.hpp";
int main() {}
$ g++-15 -fmodule-header header.hpp
header.hpp:3:18: warning: ‘void {anonymous}::S::key() [with
= int]’ used but never defined
3 | virtual void key() {}
| ^~~
$ g++-15 -fmodules -fno-module-lazy main.cpp
/usr/bin/ld: /tmp/cc5etnIe.o:(.rodata+0x10): undefined reference to `(anonymous
namespace)::S::key()'
collect2: error: ld returned 1 exit status
The issue seems to be related to header modules skipping much of
'c_parse_final_cleanups', since by not emitting vtables there they sometimes
miss instantiating template bodies, which leads to not only a confusing-looking
warning when building the header but also results in the body never being
emitted confusing importers as well.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue
[Bug c++/119527] [modules] Internal linkage virtual key function of template in header unit is not emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119527
--- Comment #1 from Nathaniel Shead ---
GCC 14 compiles and links this successfully but this is not a regression; GCC
14 just didn't handle internal-linkage entities properly and so 's' wasn't
actually imported, as can be confirmed by trying to do e.g.
int main() { s.key(); }
[Bug target/119411] [15 Regression] 5% slowdown of 505.mcf_r on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119411 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug target/119413] [15 Regression] 11% slowdown (but only 3% regression against GCC 14) of 507.cactuBSSN_r on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119413 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug c++/119512] -Wuninitialized does not diagnose use of uninitialized member in constructor initialization list due to order of init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119512 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #6 from Andrew Pinski --- There looks like a few different things going differently from PR 23 but I do think there are all related.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 119512, which changed state. Bug 119512 Summary: -Wuninitialized does not diagnose use of uninitialized member in constructor initialization list due to order of init https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119512 What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |---
[Bug c++/119512] -Wuninitialized does not diagnose use of uninitialized member in constructor initialization list due to order of init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119512 --- Comment #5 from Andrew Pinski --- Created attachment 60915 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60915&action=edit Reduced testcase
[Bug c/119526] New: standard attributes should be preserved in redeclarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119526
Bug ID: 119526
Summary: standard attributes should be preserved in
redeclarations
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: uecker at gcc dot gnu.org
Target Milestone: ---
In the following example the attribute should be propagated to test3:
struct [[deprecated]] foo;
struct foo* test1;
struct foo { int x; };
struct foo* test2;
struct foo { int x; };
struct foo* test3;
int f()
{
test2;
test3;
}
[Bug target/119340] [14 regression] ICE when building gegl-0.4.52 on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119340
--- Comment #9 from GCC Commits ---
The releases/gcc-14 branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:d54c8ebda8674fbed85e2a3c4f141ffe9fa7f8a4
commit r14-11475-gd54c8ebda8674fbed85e2a3c4f141ffe9fa7f8a4
Author: Denis Chertykov
Date: Thu Oct 17 11:12:38 2024 +0400
Reuse scratch registers generated by LRA
Test file: udivmoddi.c
problem insn: 484
Before LRA pass we have:
(insn 484 483 485 72 (parallel [
(set (reg/v:SI 143 [ __q1 ])
(plus:SI (reg/v:SI 143 [ __q1 ])
(const_int -2 [0xfffe])))
(clobber (scratch:QI))
]) "udivmoddi.c":163:405 discrim 5 186 {addsi3}
(nil))
LRA substitute all scratches with new pseudos, so we have:
(insn 484 483 485 72 (parallel [
(set (reg/v:SI 143 [ __q1 ])
(plus:SI (reg/v:SI 143 [ __q1 ])
(const_int -2 [0xfffe])))
(clobber (reg:QI 619))
]) "/mnt/d/avr-lra/udivmoddi.c":163:405 discrim 5 186 {addsi3}
(expr_list:REG_UNUSED (reg:QI 619)
(nil)))
Pseudo 619 is a special scratch register generated by LRA which is marked
in `scratch_bitmap' and can be tested by call `ira_former_scratch_p(regno)'.
In dump file (udivmoddi.c.317r.reload) we have:
Creating newreg=619
Removing SCRATCH to p619 in insn #484 (nop 3)
rescanning insn with uid = 484.
After that LRA tries to spill (reg:QI 619)
It's a bug because (reg:QI 619) is an output scratch register which is
already something like spill register.
Fragment from udivmoddi.c.317r.reload:
Choosing alt 2 in insn 484: (0) r (1) 0 (2) nYnn (3) &d {addsi3}
Creating newreg=728 from oldreg=619, assigning class LD_REGS to r728
IMHO: the bug is in lra-constraints.cc in function `get_reload_reg'
fragment of `get_reload_reg':
if (type == OP_OUT)
{
/* Output reload registers tend to start out with a conservative
choice of register class. Usually this is ALL_REGS, although
a target might narrow it (for performance reasons) through
targetm.preferred_reload_class. It's therefore quite common
for a reload instruction to require a more restrictive class
than the class that was originally assigned to the reload
register.
In these situations, it's more efficient to refine the choice
of register class rather than create a second reload register.
This also helps to avoid cycling for registers that are only
used by reload instructions. */
if (REG_P (original)
&& (int) REGNO (original) >= new_regno_start
&& INSN_UID (curr_insn) >= new_insn_uid_start
__^^
&& in_class_p (original, rclass, &new_class, true))
{
unsigned int regno = REGNO (original);
if (lra_dump_file != NULL)
{
fprintf (lra_dump_file, " Reuse r%d for output ", regno);
dump_value_slim (lra_dump_file, original, 1);
}
This condition incorrectly limits register reuse to ONLY newly generated
instructions.
i.e. LRA can reuse registers only from insns generated by himself.
IMHO:It's wrong.
Scratch registers generated by LRA also have to be reused.
The patch is very simple.
On x86_64, it bootstraps+regtests fine.
gcc/
PR target/116550
PR target/119340
* lra-constraints.cc (get_reload_reg): Reuse scratch registers
generated by LRA.
(cherry picked from commit e7393cbb5f2cae50b42713e71984064073aa378a)
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23 --- Comment #8 from Andrew Pinski --- Created attachment 60916 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60916&action=edit Another reduced testcase If I remove the first argument to Food's ctor we do get a front-end warning ...
[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119493 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug target/119473] [15 Regression] __builtin_ia32_vaesdec_v32qi() emits wrong base register with -mvaes -O2 -mapxf -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119473 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1
[Bug target/119533] RISC-V: libgo build failures (ICE) with Vector enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #4 from Vineet Gupta ---
Debug log:
`
Phase 4: Insert, modify and remove vsetvl insns.
### loop for missed vsetvl
Insert missed vsetvl info at edge(bb 31 -> bb 32): VALID (insn 663, bb 31)
Insert vsetvl insn 753:
Insert missed vsetvl info at edge(bb 31 -> bb 43): VALID (insn 663, bb 31)
Insert vsetvl insn 754:
edge(bb 42 -> bb 64):VALID (insn 663, bb 64) <-- gcc_assert() EDGE_ABNORMAL
`
So insn 663 is central to this issue. It is initially propagated into multiple
BBs and then LCM prunes it out from most of them.
`
Phase 1:
Try fuse basic block 29
Ignore curr info since prev info available with it:
prev_info: VALID (insn 663, bb 29)
curr_info: VALID (insn 664, bb 29)
VSETVL infos after phase 1
bb 29:
probability: 2.2% (guessed)
Header vsetvl info:VALID (insn 663, bb 29)
Footer vsetvl info:VALID (insn 663, bb 29)
insn 663 vsetvl info:VALID (insn 663, bb 29)
Phase 2: Lift up vsetvl info.
Try lift up 0.
Set empty bb 28 to info:VALID (insn 663, bb 29)
Try lift up 1.
Set empty bb 27 to info:VALID (insn 663, bb 28)
Try lift up 2.
Set empty bb 43 to info:VALID (insn 663, bb 27)
Try lift up 3.
Fused global info result (lift 3):
Set empty bb 31 to info:VALID (insn 663, bb 43)
Set empty bb 42 to info:VALID (insn 663, bb 43)
Phase 3: Reduce global vsetvl infos.
### 663 was present in 6 BBs
Compute LCM insert and delete data:
Expression List (14):
Expr[4]: VALID (insn 663, bb 27)
Expr[5]: VALID (insn 663, bb 28)
Expr[6]: VALID (insn 663, bb 29)
Expr[7]: VALID (insn 663, bb 31)
Expr[8]: VALID (insn 663, bb 42)
Expr[9]: VALID (insn 663, bb 43)
bitmap data:
BB 27:
avloc: n_bits = 14, set = {4 5 6 7 8 9 }
kill: n_bits = 14, set = {0 1 2 3 10 11 12 13 }
antloc: n_bits = 14, set = {4 }
transp: n_bits = 14, set = {}
avin: n_bits = 14, set = {}
avout: n_bits = 14, set = {4 5 6 7 8 9 }
del: n_bits = 14, set = {4 }
BB 28:
avloc: n_bits = 14, set = {4 5 6 7 8 9 }
kill: n_bits = 14, set = {0 1 2 3 10 11 12 13 }
antloc: n_bits = 14, set = {5 }
transp: n_bits = 14, set = {}
avin: n_bits = 14, set = {4 5 6 7 8 9 }
avout: n_bits = 14, set = {4 5 6 7 8 9 }
del: n_bits = 14, set = {5 }
BB 29:
avloc: n_bits = 14, set = {4 5 6 7 8 9 }
kill: n_bits = 14, set = {0 1 2 3 10 11 12 13 }
antloc: n_bits = 14, set = {6 }
transp: n_bits = 14, set = {}
avin: n_bits = 14, set = {4 5 6 7 8 9 }
avout: n_bits = 14, set = {4 5 6 7 8 9 }
del: n_bits = 14, set = {6 }<--- ### deleted
BB 43:
avloc: n_bits = 14, set = {4 5 6 7 8 9 }
kill: n_bits = 14, set = {0 1 2 3 10 11 12 13 }
antloc: n_bits = 14, set = {9 }
transp: n_bits = 14, set = {}
avin: n_bits = 14, set = {4 5 6 7 8 9 }
avout: n_bits = 14, set = {4 5 6 7 8 9 }
del: n_bits = 14, set = {9 }
...
LCM deleting vsetvl of block 27
LCM deleting vsetvl of block 28
LCM deleting vsetvl of block 29
LCM deleting vsetvl of block 43
VSETVL infos after phase 3
### 663 deleted from 4 of the 6 blocks
bb 27:
probability: 2.2% (guessed)
Header vsetvl info:VALID (insn 663, bb 27) (deleted)
Footer vsetvl info:VALID (insn 663, bb 27) (deleted)
bb 28:
probability: 2.2% (guessed)
Header vsetvl info:VALID (insn 663, bb 28) (deleted)
Footer vsetvl info:VALID (insn 663, bb 28) (deleted)
bb 29:
probability: 2.2% (guessed)
Header vsetvl info:VALID (insn 663, bb 29) (deleted)
Footer vsetvl info:VALID (insn 663, bb 29) (deleted)
insn 663 vsetvl info:VALID (insn 663, bb 29) (deleted)
bb 31:
probability: 1.9% (guessed)
Header vsetvl info:VALID (insn 663, bb 31)
Footer vsetvl info:VALID (insn 663, bb 31)
bb 42:
probability: 1.9% (guessed)
Header vsetvl info:VALID (insn 663, bb 42)
Footer vsetvl info:VALID (insn 663, bb 42)
bb 43:
probability: 1.9% (guessed)
Header vsetvl info:VALID (insn 663, bb 43) (deleted)
Footer vsetvl info:VALID (insn 663, bb 43) (deleted)
`
Comparing the asm-output of --param=vsetvl-strategy=simple (which works), the
BB layout is generally sane and it seems we can simply skip the abnormal edge.
FWWI I did try to tinker with LCM a bit, skipping abnormal edges in
invalid_opt_bb_p () which creates the sets for LCM, but it didn't matter.
[Bug tree-optimization/119534] [12/13/14/15 regression] ICE when building libaom-3.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119534 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-03-29 Target Milestone|15.0|12.5 Known to fail||12.1.0 Ever confirmed|0 |1 Known to work||11.1.0, 11.4.0 Summary|[14/15 regression] ICE when |[12/13/14/15 regression] |building libaom-3.10.0 |ICE when building ||libaom-3.10.0 --- Comment #3 from Andrew Pinski --- Confirmed, my reduced testcase failed since GCC 12.
[Bug tree-optimization/119534] [15 regression] ICE when building libaom-3.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119534 --- Comment #2 from Andrew Pinski --- Created attachment 60921 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60921&action=edit Reduced testcase
[Bug tree-optimization/119535] [15 regression] Firefox fails to build (SkRasterPipeline_opts.h:1603:31: error: cannot tail-call: other reasons)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119535 --- Comment #1 from Andrew Pinski --- >(why is -pthread needed?) Because that enables atomic update for profiling rather than using non-atomics.
[Bug target/119533] RISC-V: libgo build failures (ICE) with Vector enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533 --- Comment #5 from Vineet Gupta --- Proposed fix https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679657.html
[Bug tree-optimization/119535] [15 regression] Firefox fails to build (SkRasterPipeline_opts.h:1603:31: error: cannot tail-call: other reasons)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119535 --- Comment #2 from Sam James --- (In reply to Andrew Pinski from comment #1) Ah, I thought you always had to do -fprofile-update=atomic for that.
[Bug tree-optimization/119535] [15 regression] Firefox fails to build (SkRasterPipeline_opts.h:1603:31: error: cannot tail-call: other reasons)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119535 --- Comment #4 from Andrew Pinski --- Reducing one of the -fprofile-generate failures.
[Bug tree-optimization/119393] [15 Regression] Worse vectorization of imagick_r hot loop on aarch64 since r15-5024-g2a2e6784074e1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug c++/118961] ICE g++ modules with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118961 --- Comment #3 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:3258c89fbb092412a69b689425e77972e7a1c567 commit r15-9024-g3258c89fbb092412a69b689425e77972e7a1c567 Author: Nathaniel Shead Date: Fri Mar 28 23:38:26 2025 +1100 c++/modules: Fix modules and LTO with header units [PR118961] This patch makes some adjustments required to get a simple modules testcase working with LTO. There are two main issues fixed. Firstly, modules only streams the maybe-in-charge constructor, and any clones are recreated on stream-in. These clones are copied from the existing function decl and then adjusted. This caused issues because the clones were getting incorrectly marked as abstract, since after clones have been created (in the imported file) the maybe-in-charge decl gets marked as abstract. So this patch just ensures that clones are always created as non-abstract. The second issue is that we need to explicitly tell cgraph that explicit instantiations need to be emitted, otherwise LTO will elide them (as they don't necessarily appear to be used directly) and cause link errors. Additionally, expand_or_defer_fn doesn't setup comdat groups for explicit instantiations, so we need to do that here as well. Currently this is all handled in 'mark_decl_instantiated'; this patch splits out the linkage handling into a separate function that we can call from modules code, maybe in GCC16 we could move this somewhere more central. PR c++/118961 gcc/cp/ChangeLog: * class.cc (copy_fndecl_with_name): Mark clones as non-abstract. * cp-tree.h (setup_explicit_instantiation_definition_linkage): Declare new function. * module.cc (trees_in::read_var_def): Use it. (module_state::read_cluster): Likewise. * pt.cc (setup_explicit_instantiation_definition_linkage): New function. (mark_decl_instantiated): Use it. gcc/testsuite/ChangeLog: * g++.dg/modules/lto-1.h: New test. * g++.dg/modules/lto-1_a.H: New test. * g++.dg/modules/lto-1_b.C: New test. * g++.dg/modules/lto-1_c.C: New test. * g++.dg/modules/lto-2_a.H: New test. * g++.dg/modules/lto-2_b.C: New test. * g++.dg/modules/lto-3_a.H: New test. * g++.dg/modules/lto-3_b.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill
[Bug c/119528] __attribute__((deprecated(text)) triggers with __attribute__((malloc(deallocator, index)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
You use the deprecated function in the attribute argument, how is that
different from any other uses?
If you don't want warning for that case, do
void free_foo(FOO* var);
__attribute__((deprecated("deprecated")) __attribute__((malloc(free_foo, 1)))
FOO* create_foo(void);
__attribute__((deprecated("deprecated")) void free_foo(FOO* var);
[Bug c/119528] __attribute__((deprecated(text)) triggers with __attribute__((malloc(deallocator, index)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528 --- Comment #3 from Jakub Jelinek --- (In reply to akallabeth+gnu from comment #2) > as for your suggestion, this will fail as the function designated > deallocator has not been declared... You clearly have not tried that (sure, with the missing ) after deprecated attributes added.
[Bug c/119528] __attribute__((deprecated(text)) triggers with __attribute__((malloc(deallocator, index)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528
--- Comment #2 from akallabeth+gnu at posteo dot net ---
well, that it is not an actual use?
nigher free_foo nor create_foo (the function) are used anywhere in the
code.
how do you consider deprecating a function helpful if every deprecation
produces a false positive on every header include?
as for your suggestion, this will fail as the function designated
deallocator has not been declared...
On 3/29/25 13:10, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528
>
> Jakub Jelinek changed:
>
> What|Removed |Added
>
> CC||jakub at gcc dot gnu.org
>
> --- Comment #1 from Jakub Jelinek ---
> You use the deprecated function in the attribute argument, how is that
> different from any other uses?
> If you don't want warning for that case, do
> void free_foo(FOO* var);
> __attribute__((deprecated("deprecated")) __attribute__((malloc(free_foo, 1)))
> FOO* create_foo(void);
> __attribute__((deprecated("deprecated")) void free_foo(FOO* var);
>
[Bug cobol/119283] cobol FE uses memrchr unconditionally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283 --- Comment #5 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:9018336252463ffed28f01badfdea2a3ca3ba5c8 commit r15-9028-g9018336252463ffed28f01badfdea2a3ca3ba5c8 Author: Iain Sandoe Date: Sat Mar 15 22:30:20 2025 + libiberty, gcc: Add memrchr to libiberty and use it [PR119283]. This adds an implementation of memrchr to libiberty and arranges to configure gcc to use it, if the host does not have it. PR cobol/119283 gcc/ChangeLog: * config.in: Regenerate. * configure: Regenerate. * configure.ac: Check for host memrchr. include/ChangeLog: * libiberty.h (memrchr): New. libiberty/ChangeLog: * Makefile.in: Add memrchr build rules. * config.in: Regenerate. * configure: Regenerate. * configure.ac: Check for memrchr. * functions.texi: Document memrchr. * memrchr.c: New file. Signed-off-by: Iain Sandoe
[Bug tree-optimization/119530] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-vrp -fno-inline" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119530
Sam James changed:
What|Removed |Added
Summary|wrong code at -O{s,2,3} |[15 regression] wrong code
|with "-fno-tree-vrp |at -O{s,2,3} with
|-fno-inline" on |"-fno-tree-vrp -fno-inline"
|x86_64-linux-gnu|on x86_64-linux-gnu
Version|unknown |15.0
Keywords||wrong-code
Target Milestone|--- |15.0
[Bug c++/64500] push_to_top_level() shows up high during build of modern C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64500 --- Comment #15 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5ac4be28822a4e6f506a69096f92d4675a7d5a72 commit r15-9026-g5ac4be28822a4e6f506a69096f92d4675a7d5a72 Author: Jason Merrill Date: Mon Mar 24 15:28:04 2025 -0400 c++: optimize push_to_top_level [PR64500] Profiling showed that the loop to save away IDENTIFIER_BINDINGs from open binding levels was taking 5% of total compilation time in the PR116285 testcase. This turned out to be because we were unnecessarily trying to do this for namespaces, whose bindings are found through DECL_NAMESPACE_BINDINGS, not IDENTIFIER_BINDING. As a result we would frequently loop through everything in std::, checking whether it needs to be stored, and never storing anything. This change actually appears to speed up compilation for the PR116285 testcase by ~20%. The replaced comments referred either to long-replaced handling of classes and templates, or to wanting b to point to :: when the loop exits. PR c++/64500 PR c++/116285 gcc/cp/ChangeLog: * name-lookup.cc (push_to_top_level): Don't try to store_bindings for namespace levels.
[Bug c++/116285] Compilation of nodejs/v8's v8_base_without_compiler.runtime-temporal.cc is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116285 --- Comment #7 from Sam James --- Thanks! I'm going to bisect the get_class_binding_direct issue unless someone has a guess.
[Bug c++/116285] Compilation of nodejs/v8's v8_base_without_compiler.runtime-temporal.cc is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116285 --- Comment #8 from Sam James --- (In reply to Andi Kleen from comment #2) > 0.94% of the cycles are iterative_hash, so you might get another slight > improvement from https://github.com/andikleen/gcc/commits/rapidhash-1 > which switches the hash function to something more modern > (still looking for supporting data that it actually helps) It actually seems worse but maybe bad luck? 7.14% cc1plus cc1plus [.] get_class_binding_direct 4.52% cc1plus cc1plus [.] hash_table, false, xcallocator>::find_slot_with_hash 2.88% cc1plus cc1plus [.] ggc_internal_alloc_no_dtor 2.74% cc1plus libc.so.6 [.] __memset_avx2_unaligned_erms 2.67% cc1plus cc1plus [.] hash_table::find_slot_with_hash
[Bug fortran/115983] ICE on valid code in gfc_is_nodesc_array, at fortran/trans-types.cc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- A little bit reduced: module m type, abstract :: t1_t contains generic :: assignment(=) => assign procedure (t1_assign), deferred :: assign end type t1_t type, extends (t1_t) :: t2_t contains procedure :: assign => t2_assign end type t2_t type :: t3_t end type t3_t abstract interface subroutine t1_assign (q, q2) import class(t1_t), intent(inout) :: q class(t1_t), intent(in) :: q2 end subroutine t1_assign end interface interface module subroutine t2_assign (q, q2) class(t2_t), intent(inout) :: q class(t1_t), intent(in) :: q2 end subroutine t2_assign end interface interface elemental module function t3_get_t2 (qn) result (t2) type(t2_t) :: t2 type(t3_t), intent(in) :: qn end function t3_get_t2 end interface contains subroutine s_iterator_extract_t2_multi (it, t2) type(t2_t), dimension(:), intent(out) :: t2 type(t3_t), dimension(2) :: qn t2 = t3_get_t2 (qn) end subroutine s_iterator_extract_t2_multi end module m The ICE goes away if t2 is declared as type(t2_t), dimension(2), intent(out) :: t2 in subroutine s_iterator_extract_t2_multi.
[Bug c++/119529] New: Template-id does not match any template declaration (for template friend function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119529
Bug ID: 119529
Summary: Template-id does not match any template declaration
(for template friend function)
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jesse at mind dot net
Target Milestone: ---
The attached program fails to compile, producing:
unfriendly-template.cpp:13:13: error: template-id ‘f<>’ for ‘void f<>(int)’
does not match any template declaration
13 | friend void f<>(int);
| ^~~
unfriendly-template.cpp:12:7: note: candidate is: ‘void::f(int)’
12 | void f(int) {}
| ^
[Bug c++/119529] Template-id does not match any template declaration (for template friend function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119529 Jesse Williamson changed: What|Removed |Added CC||jesse at mind dot net --- Comment #1 from Jesse Williamson --- Created attachment 60917 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60917&action=edit triggers unfriendly template friend function g++ -std=c++23 -Wall -Wextra -pedantic -c unfriendly-template.cpp
[Bug c++/119529] Template-id does not match any template declaration (for template friend function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119529 --- Comment #2 from Jesse Williamson --- Changing the name of the free function to differ from the class member compiles, e.g.: friend void g<>(int);
[Bug c++/119529] Template-id does not match any template declaration (for template friend function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119529 Jesse Williamson changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jesse Williamson --- marking as dup *** This bug has been marked as a duplicate of bug 117422 ***
[Bug c++/119529] Template-id does not match any template declaration (for template friend function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119529 --- Comment #3 from Jesse Williamson --- Oh, shoot, I thought I'd checked carefully but I think this is a duplicate of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117422
[Bug tree-optimization/119493] [12/13/14/15 Regression] missing tail call to self with struct in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119493
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
I'd say for musttail calls recursive inlining should never be desirable,
instead we should have turned that into a tail recursion.
Now, except for early inlining I think it should have happened already, IPA
inlining is done on functions which made it through all pre-IPA optimizations
which includes the tailr pass, so I think we should simply improve the tailr
pass to handle it.
With -fno-early-inlining -O2 it still fails:
Cannot handle D.2905.n_recurses = 0;
struct MyStruct foo (struct MyStruct m)
{
unsigned int m$n_recurses;
struct MyStruct D.2897;
struct MyStruct D.2905;
unsigned int _3;
:
m$n_recurses_9 = m.n_recurses;
if (m$n_recurses_9 == 0)
goto ; [INV]
else
goto ; [INV]
:
D.2905.n_recurses = 0;
goto ; [INV]
:
_3 = m$n_recurses_9 + 4294967295;
D.2897.n_recurses = _3;
D.2905 = foo (D.2897); [must tail call]
:
return D.2905;
}
but I don't understand why it just couldn't do m = D.2897; goto ; in that
case.
Early inlining is more complicated, either we need to arrange for tailr to be
run on the to be inlined body before it is attempted to be early inlined, or we
need to optimize that (perhaps just for musttail calls) during early inlining
because we shouldn't inline one invocation of foo and keep there foo call.
[Bug c/119528] New: __attribute__((deprecated(text)) triggers with __attribute__((malloc(deallocator, index)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528
Bug ID: 119528
Summary: __attribute__((deprecated(text)) triggers with
__attribute__((malloc(deallocator, index)))
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: akallabeth+gnu at posteo dot net
Target Milestone: ---
Got the following (deprecated) pair of allocator/deallocators declared in a
header:
__attribute__((deprecated("deprecated")) void free_foo(FOO* var);
__attribute__((deprecated("deprecated")) __attribute__((malloc(free_foo, 1)))
FOO* create_foo(void);
now this alone is enough to trigger deprecation warnings during a compile every
time the header is included.
looks like `GCC` considers the __attribute__((malloc(free_foo, 1))) as usage of
free_foo
for comparison, tried to compile the same with clang (19.7.1) and there there
are no warnings emitted.
[Bug debug/119531] New: GCC generates incomplete DWARF debug information for TLS variables on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119531 Bug ID: 119531 Summary: GCC generates incomplete DWARF debug information for TLS variables on aarch64 Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: hmeyer.eu at gmail dot com Target Milestone: --- Created attachment 60918 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60918&action=edit Debug information for aarch64 (no location) and for comparison x86_64 Debug information for TLS variables is missing the DW_AT_location attribute on aarch64. I first noticed with GCC 13 when trying to print glibc tcache, I verified with trunk on Compiler Explorer, it is specific to aarch64, does not happen for x86_64, i686, armhf. I have also reproduced the problem with GCC 10.2.1. The variables shows up with correct TLS offset in the ELF symtab. The location attribute is the only way to specify in DWARF that this is a TLS variable. Minimal example (attachments are created on Ubuntu 24.10/GCC 14.2.0) echo "thread_local int tls_var;" > tls_example.cpp aarch64-linux-gnu-g++ -g -c tls_example.cpp aarch64-linux-gnu-readelf --debug-dump=info tls_example.o GDB displays "optimized away" for such variables without a location attribute.
[Bug debug/119531] GCC generates incomplete DWARF debug information for TLS variables on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119531 Henning Meyer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Henning Meyer --- This is a dup of Bug 97344 (2020), which is itself a dup of 83010 from 2017. Apparently, binutils is lacking support, filed as https://sourceware.org/bugzilla/show_bug.cgi?id=28351 with no progress since filing in 2021 *** This bug has been marked as a duplicate of bug 97344 ***
[Bug debug/97344] aarch64 tls debuginfo missing location info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97344 Henning Meyer changed: What|Removed |Added CC||hmeyer.eu at gmail dot com --- Comment #9 from Henning Meyer --- *** Bug 119531 has been marked as a duplicate of this bug. ***
[Bug c/119528] __attribute__((deprecated(text)) triggers with __attribute__((malloc(deallocator, index)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528 --- Comment #5 from Jakub Jelinek --- You obviously need to declare the free function first, but without deprecated attribute and just add that attribute afterwards when you'll no longer use it in your code. That isn't any different from using it e.g. in some inline function which will be then deprecated as well etc.
[Bug c/119528] __attribute__((deprecated(text)) triggers with __attribute__((malloc(deallocator, index)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528 --- Comment #4 from akallabeth+gnu at posteo dot net --- you jump to conclusions... * this is called a simplified example, if you want the full code go compile htts://github.com/freerdp/freerdp * did you try yourself? Then please explain the following: [9/158] Building C object libfreerdp/CMakeFiles/freerdp.dir/utils/smartcard_call.c.o FAILED: libfreerdp/CMakeFiles/freerdp.dir/utils/smartcard_call.c.o /usr/bin/ccache /usr/bin/cc -DEXT_PATH=\"/tmp/xxx/lib/freerdp3/extensions\" -DFREERDP_EXPORTS -DNONAMELESSUNION -DWINPR_TIMEZONE_FILE=\"/etc/timezone\" -DWITHOUT_FREERDP_3x_DEPRECATED -DWITH_FREERDP_DEPRECATED_COMMANDLINE -DWITH_OPENSSL -DWITH_SMARTCARD_EMULATE -DWITH_VERBOSE_WINPR_ASSERT -D_FILE_OFFSET_BITS=64 -Dfreerdp_EXPORTS -I/home/nin/src/freerdp/winpr/include -I/home/nin/src/freerdp/xxx/winpr/include -I/home/nin/src/freerdp/xxx -I/home/nin/src/freerdp/xxx/include -I/home/nin/src/freerdp/include -Wno-incompatible-pointer-types -Wno-int-conversion -fvisibility=hidden -fno-omit-frame-pointer -Wredundant-decls -Wimplicit-function-declaration -fvisibility=hidden -g -O2 -std=gnu11 -flto=auto -fno-fat-lto-objects -fPIC -MD -MT libfreerdp/CMakeFiles/freerdp.dir/utils/smartcard_call.c.o -MF libfreerdp/CMakeFiles/freerdp.dir/utils/smartcard_call.c.o.d -o libfreerdp/CMakeFiles/freerdp.dir/utils/smartcard_call.c.o -c /home/nin/src/freerdp/libfreerdp/utils/smartcard_call.c In file included from /home/nin/src/freerdp/winpr/include/winpr/winpr.h:22, from /home/nin/src/freerdp/winpr/include/winpr/assert.h:27, from /home/nin/src/freerdp/libfreerdp/utils/smartcard_call.c:28: /home/nin/src/freerdp/include/freerdp/codecs.h:80:27: error: ‘freerdp_client_codecs_free’ undeclared here (not in a function); did you mean ‘freerdp_client_codecs_reset’? 80 | WINPR_ATTR_MALLOC(freerdp_client_codecs_free, 1) | ^~ /home/nin/src/freerdp/winpr/include/winpr/platform.h:542:31: note: in definition of macro ‘WINPR_ATTR_MALLOC’ 542 | __attribute__((malloc(deallocator, ptrindex), warn_unused_result)) /** @since version 3.3.0 */ | ^~~ oh, just so there are no misunderstandings: 13:34 $ cc --version cc (Debian 14.2.0-19) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. regards On 3/29/25 13:21, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528 > > --- Comment #3 from Jakub Jelinek --- > (In reply to akallabeth+gnu from comment #2) >> as for your suggestion, this will fail as the function designated >> deallocator has not been declared... > > You clearly have not tried that (sure, with the missing ) after deprecated > attributes added. >
[Bug c++/116285] Compilation of nodejs/v8's v8_base_without_compiler.runtime-temporal.cc is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116285 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5ac4be28822a4e6f506a69096f92d4675a7d5a72 commit r15-9026-g5ac4be28822a4e6f506a69096f92d4675a7d5a72 Author: Jason Merrill Date: Mon Mar 24 15:28:04 2025 -0400 c++: optimize push_to_top_level [PR64500] Profiling showed that the loop to save away IDENTIFIER_BINDINGs from open binding levels was taking 5% of total compilation time in the PR116285 testcase. This turned out to be because we were unnecessarily trying to do this for namespaces, whose bindings are found through DECL_NAMESPACE_BINDINGS, not IDENTIFIER_BINDING. As a result we would frequently loop through everything in std::, checking whether it needs to be stored, and never storing anything. This change actually appears to speed up compilation for the PR116285 testcase by ~20%. The replaced comments referred either to long-replaced handling of classes and templates, or to wanting b to point to :: when the loop exits. PR c++/64500 PR c++/116285 gcc/cp/ChangeLog: * name-lookup.cc (push_to_top_level): Don't try to store_bindings for namespace levels.
[Bug c/119528] __attribute__((deprecated(text)) triggers with __attribute__((malloc(deallocator, index)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528 --- Comment #6 from akallabeth+gnu at posteo dot net --- oh, mea culpa :) did miss the first declaration in your sample. with that it works. this still feels like a workaround (and, as mentioned, with clang there are no such warnings) regards On 3/29/25 13:42, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528 > > --- Comment #5 from Jakub Jelinek --- > You obviously need to declare the free function first, but without deprecated > attribute and just add that attribute afterwards when you'll no longer use it > in your code. > That isn't any different from using it e.g. in some inline function which will > be then deprecated as well etc. >
[Bug c++/64500] push_to_top_level() shows up high during build of modern C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64500 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |15.0 Status|NEW |RESOLVED --- Comment #16 from Jason Merrill --- Fixed for GCC 15.
[Bug c++/117422] Error: template parameter was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117422 Jesse Williamson changed: What|Removed |Added CC||jesse at mind dot net --- Comment #6 from Jesse Williamson --- *** Bug 119529 has been marked as a duplicate of this bug. ***
[Bug cobol/119283] cobol FE uses memrchr unconditionally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Iain Sandoe --- fixed for trunk
[Bug tree-optimization/119530] New: wrong code at -O{s,2,3} with "-fno-tree-vrp -fno-inline" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119530
Bug ID: 119530
Summary: wrong code at -O{s,2,3} with "-fno-tree-vrp
-fno-inline" on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression and doesn't reproduce with 14.2 and
earlier.
Compiler Explorer: https://godbolt.org/z/x9r5819To
[612] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250329 (experimental) (GCC)
[613] %
[613] % gcctk -O3 small.c; ./a.out
[614] % gcctk -O3 -fno-tree-vrp -fno-inline small.c
[615] % ./a.out
Aborted
[616] % cat small.c
struct a {
int b;
};
int c;
char d;
static int e(long f) { return f < 0; }
static void g(unsigned f) { c = e(~f); }
int main() {
int h;
struct a i = {128};
h = d > i.b;
g(h);
if (h)
__builtin_abort();
if (c)
__builtin_abort();
return 0;
}
[Bug tree-optimization/119530] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-vrp -fno-inline" on x86_64-linux-gnu since r15-6294-g96fb71883d438b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119530
Sam James changed:
What|Removed |Added
Summary|[15 regression] wrong code |[15 regression] wrong code
|at -O{s,2,3} with |at -O{s,2,3} with
|"-fno-tree-vrp -fno-inline" |"-fno-tree-vrp -fno-inline"
|on x86_64-linux-gnu |on x86_64-linux-gnu since
||r15-6294-g96fb71883d438b
--- Comment #2 from Sam James ---
r15-6294-g96fb71883d438b
[Bug tree-optimization/119530] [15 regression] wrong code at -O{s,2,3} with "-fno-tree-vrp -fno-inline" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119530 Sam James changed: What|Removed |Added Priority|P3 |P1 Last reconfirmed||2025-03-29 CC||jamborm at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Sam James --- -fno-ipa-cp works
[Bug middle-end/119532] New: [avr] ICE: in build_minus_one_cst, at tree.cc:2698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119532
Bug ID: 119532
Summary: [avr] ICE: in build_minus_one_cst, at tree.cc:2698
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
extern _Fract sinuhk_deg (unsigned short _Accum);
_Fract cosuhk_deg (unsigned short _Accum deg)
{
unsigned short _Accum _90_deg = 90uhk;
__asm ("" : "+r" (_90_deg));
// The implementation of sinuhk_deg() is such that it never returns -1,
// hence negating the result is no issue.
return deg <= _90_deg
? sinuhk_deg (_90_deg - deg)
: -sinuhk_deg (deg - _90_deg);
}
$ avr-gcc ice-m1.c -S -Os
during GIMPLE pass: tailr
ice-m1.c: In function 'cosuhk_deg':
ice-m1.c:13:1: internal compiler error: in build_minus_one_cst, at tree.cc:2698
13 | }
| ^
Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --with-long-double=64
--disable-libcc1 --disable-shared --enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250323 (experimental) (GCC)
[Bug tree-optimization/119532] [avr] ICE: in build_minus_one_cst with _Accum/_Fract types , at tree.cc:2698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119532 --- Comment #1 from Andrew Pinski --- I should mention this is most likely reproducible on mips because those are the only other target that has _Fract/_Accum support.
[Bug libstdc++/119517] formatter for chrono types are underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119517 --- Comment #2 from Tomasz Kamiński --- Jonathan noted that zoned_time is specified in standard to accept unconstrained FormatContext in [time.format] p19 (https://eel.is/c++draft/time.format#19).
[Bug target/119533] RISC-V: libgo build failures (ICE) with Vector enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533 --- Comment #3 from Andrew Pinski --- I suspect if you run the testsuite with -fnon-call-exceptions you might find a reduced C (or C++) testcae for the same issue.
[Bug target/119533] RISC-V: libgo build failures (ICE) with Vector enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533 --- Comment #2 from Andrew Pinski --- gcc_assert (!(eg->flags & EDGE_ABNORMAL)); Yep.
[Bug target/119533] New: RISC-V: libgo build failures (ICE) with Vector enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
Bug ID: 119533
Summary: RISC-V: libgo build failures (ICE) with Vector enabled
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: vineetg at gcc dot gnu.org
Reporter: vineetg at gcc dot gnu.org
CC: jeffreyalaw at gmail dot com, rdapp.gcc at gmail dot com,
rdapp at gcc dot gnu.org
Target Milestone: ---
Created attachment 60919
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60919&action=edit
go test
When building a vector enabled toolchain (--with-arch=rv64gcv) with go frontend
enabled (--enable-languages=c,c++,fortran,go) there's an ICE in vsetvl pass
when building libgo.
during RTL pass: vsetvl
../../.././gcc/libgo/go/go/ast/filter.go: In function
'go/ast.MergePackageFiles':
../../.././gcc/libgo/go/go/ast/filter.go:344:1: internal compiler error: in
emit_vsetvl, at config/riscv/riscv-vsetvl.cc:3394
344 | func MergePackageFiles(pkg *Package, mode MergeMode) *File {
| ^
0x3087766 internal_error(char const*, ...)
../.././gcc/gcc/diagnostic-global-context.cc:517
0xcc9ebc fancy_abort(char const*, int, char const*)
../.././gcc/gcc/diagnostic.cc:1749
0xbf81a2 pre_vsetvl::emit_vsetvl()
../.././gcc/gcc/config/riscv/riscv-vsetvl.cc:3394
0x1906105 pass_vsetvl::lazy_vsetvl()
../.././gcc/gcc/config/riscv/riscv-vsetvl.cc:3644
0x190646a pass_vsetvl::execute(function*)
../.././gcc/gcc/config/riscv/riscv-vsetvl.cc:3673
0x190646a pass_vsetvl::execute(function*)
../.././gcc/gcc/config/riscv/riscv-vsetvl.cc:3656
[Bug target/119533] RISC-V: libgo build failures (ICE) with Vector enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533 --- Comment #1 from Andrew Pinski --- Note this is most likely exposed by -fnon-call-exceptions which the go front-end enables by default.
[Bug tree-optimization/119534] [15 regression] ICE when building libaom-3.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119534 --- Comment #1 from Andrew Pinski --- Reducing ...
[Bug c++/116285] Compilation of nodejs/v8's v8_base_without_compiler.runtime-temporal.cc is slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116285 ak at gcc dot gnu.org changed: What|Removed |Added CC||ak at gcc dot gnu.org --- Comment #9 from ak at gcc dot gnu.org --- Thanks for testing. Too bad it didn't help.
[Bug tree-optimization/119534] New: [15 regression] ICE when building libaom-3.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119534 Bug ID: 119534 Summary: [15 regression] ICE when building libaom-3.10.0 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 60920 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60920&action=edit highbd_temporal_filter_avx2.c.i.xz ``` $ gcc -c ./CMakeFiles/aom_av1_encoder_avx2_intrinsics.dir/av1/encoder/x86/highbd_temporal_filter_avx2.c.i -m32 -march=icelake-server -O3 /var/tmp/portage/media-libs/libaom-3.10.0/work/libaom-3.10.0/av1/encoder/x86/highbd_temporal_filter_avx2.c: In function ‘av1_highbd_apply_temporal_filter_avx2’: /var/tmp/portage/media-libs/libaom-3.10.0/work/libaom-3.10.0/av1/encoder/x86/highbd_temporal_filter_avx2.c:368:6: error: integral result type precision does not match field size of ‘bit_field_ref’ 368 | void av1_highbd_apply_temporal_filter_avx2( | ^ _4362 = BIT_FIELD_REF ; [...] _2962 = BIT_FIELD_REF ; /var/tmp/portage/media-libs/libaom-3.10.0/work/libaom-3.10.0/av1/encoder/x86/highbd_temporal_filter_avx2.c:368:6: error: integral result type precision does not match field size of ‘bit_field_ref’ _2949 = BIT_FIELD_REF ; /var/tmp/portage/media-libs/libaom-3.10.0/work/libaom-3.10.0/av1/encoder/x86/highbd_temporal_filter_avx2.c:368:6: error: integral result type precision does not match field size of ‘bit_field_ref’ _2942 = BIT_FIELD_REF ; /var/tmp/portage/media-libs/libaom-3.10.0/work/libaom-3.10.0/av1/encoder/x86/highbd_temporal_filter_avx2.c:368:6: error: integral result type precision does not match field size of ‘bit_field_ref’ _2936 = BIT_FIELD_REF ; during GIMPLE pass: vect /var/tmp/portage/media-libs/libaom-3.10.0/work/libaom-3.10.0/av1/encoder/x86/highbd_temporal_filter_avx2.c:368:6: internal compiler error: verify_gimple failed 0x55d5720c64e2 internal_error(char const*, ...) /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:517 0x55d570bef62f verify_gimple_in_cfg(function*, bool, bool) /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-cfg.cc:5682 0x55d57228ff82 execute_function_todo /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/passes.cc:2101 0x55d5721ad726 do_per_function /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/passes.cc:1700 0x55d5721ad726 execute_todo /usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/passes.cc:2155 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. ``` --- ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python --enable-libphobos --enable-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran,ada,m2,rust --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 15.0. p, commit c2b5b58acd2b0240ed361bbc9a94bf61d2d26f8e' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-offload-defaulted --enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp --enable-libada --enable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --without-isl --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-build-config='bootstrap-lto bootstrap-cet' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.1 20250329 (experimental) eb26b667518c951
[Bug tree-optimization/119534] [15 regression] ICE when building libaom-3.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119534 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |15.0
[Bug tree-optimization/119535] [15 regression] Firefox fails to build (SkRasterPipeline_opts.h:1603:31: error: cannot tail-call: other reasons)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119535
--- Comment #3 from Andrew Pinski ---
(In reply to Sam James from comment #2)
> (In reply to Andrew Pinski from comment #1)
>
> Ah, I thought you always had to do -fprofile-update=atomic for that.
gcc.cc has the following for the default cc1 options spec:
%{pthread:-fprofile-update=prefer-atomic}
[Bug tree-optimization/119536] [15 regression] Python fails to build (error: cannot tail-call: call invocation refers to locals)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119536 --- Comment #1 from Sam James --- Just `gcc -c ceval.i -O3` (or -O2 or ...) is enough.
[Bug tree-optimization/119536] [15 regression] Python fails to build (error: cannot tail-call: call invocation refers to locals)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119536 --- Comment #2 from Andrew Pinski --- I am 99% sure this is the known issue where local variables escape causing musttail to fail.
[Bug tree-optimization/119535] New: [15 regression] Firefox fails to build (SkRasterPipeline_opts.h:1603:31: error: cannot tail-call: other reasons)
='Gentoo Hardened 15.0. p, commit c2b5b58acd2b0240ed361bbc9a94bf61d2d26f8e' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-offload-defaulted --enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp --enable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-build-config='bootstrap-O3 bootstrap-lto' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.1 20250329 (experimental) 9018336252463ffed28f01badfdea2a3ca3ba5c8 (Gentoo Hardened 15.0. p, commit c2b5b58acd2b0240ed361bbc9a94bf61d2d26f8e) ```
[Bug tree-optimization/119536] New: [15 regression] Python fails to build (error: cannot tail-call: call invocation refers to locals)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119536 Bug ID: 119536 Summary: [15 regression] Python fails to build (error: cannot tail-call: call invocation refers to locals) Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: tail-call Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 60923 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60923&action=edit ceval.i.xz ``` $ git clone https://github.com/python/cpython && cd cpython $ ./configure --with-tail-call-interp $ make $ gcc -c -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall-std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I./Include/internal/mimalloc -I. -I./Include -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c [...] Python/generated_cases.c.h: In function ‘_TAIL_CALL_LOAD_FROM_DICT_OR_DEREF’: Python/ceval_macros.h:89:32: error: cannot tail-call: call invocation refers to locals 89 | Py_MUSTTAIL return (_TAIL_CALL_##name)(TAIL_CALL_ARGS); \ | ^~~ Python/generated_cases.c.h:8944:17: note: in expansion of macro ‘JUMP_TO_LABEL’ 8944 | JUMP_TO_LABEL(error); | ^ Python/ceval_macros.h:89:32: error: cannot tail-call: call invocation refers to locals 89 | Py_MUSTTAIL return (_TAIL_CALL_##name)(TAIL_CALL_ARGS); \ |^~~ Python/generated_cases.c.h:8953:21: note: in expansion of macro ‘JUMP_TO_LABEL’ 8953 | JUMP_TO_LABEL(error); | ^ Python/ceval_macros.h:85:50: error: cannot tail-call: call invocation refers to locals 85 | Py_MUSTTAIL return (INSTRUCTION_TABLE[opcode])(TAIL_CALL_ARGS); \ | ~~^ Python/ceval_macros.h:146:9: note: in expansion of macro ‘DISPATCH_GOTO’ 146 | DISPATCH_GOTO(); \ | ^ Python/generated_cases.c.h:8965:13: note: in expansion of macro ‘DISPATCH’ 8965 | DISPATCH(); | ^~~~ [...] ``` --- ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python --enable-libphobos --enable-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran,ada,cobol,m2,rust --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 15.0. p, commit c2b5b58acd2b0240ed361bbc9a94bf61d2d26f8e' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-offload-defaulted --enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp --enable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-build-config='bootstrap-O3 bootstrap-lto' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.1 20250329 (experimental) 9018336252463ffed28f01badfdea2a3ca3ba5c8 (Gentoo Hardened 15.0. p, commit c2b5b58acd2b0240ed361bbc9a94bf61d2d26f8e) ```
[Bug tree-optimization/119536] [15 regression] Python fails to build (error: cannot tail-call: call invocation refers to locals)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119536 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Just try https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679182.html
[Bug middle-end/119537] New: ICE with [[gnu::assume]] vs computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119537
Bug ID: 119537
Summary: ICE with [[gnu::assume]] vs computed goto
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
This comes from lcamtuf: https://x.com/lcamtuf/status/1905745238666490269
```
#include
int main() {
goto *&&x;
[[gnu::assume( ({x: puts("hi");}) )]];
}
```
```
$ gcc-15 a.c -c
during GIMPLE pass: cfg
a.c: In function ‘main’:
a.c:3:5: internal compiler error: Segmentation fault
3 | int main() {
| ^~~~
0x5eb37ea0acee internal_error(char const*, ...)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:517
0x5eb37e1815d9 crash_signal
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:323
0x78051861fd5f ???
/usr/src/debug/sys-libs/glibc-2.41./glibc-2.41./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x5eb37d3a64d3 cleanup_control_flow_bb
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-cfgcleanup.cc:313
0x5eb37ec63dbb cleanup_control_flow_pre
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-cfgcleanup.cc:925
0x5eb37ec62880 cleanup_tree_cfg_noloop
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-cfgcleanup.cc:1090
0x5eb37ec62880 cleanup_tree_cfg(unsigned int)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-cfgcleanup.cc:1205
0x5eb37ec44585 execute_build_cfg
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-cfg.cc:380
0x5eb37ec44585 execute
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-cfg.cc:414
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug middle-end/119537] ICE with [[gnu::assume]] vs computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119537 Andrew Pinski changed: What|Removed |Added Keywords||stmt-expr --- Comment #1 from Andrew Pinski --- This is invalid for 2 reasons. it is undefined for jumping into a statement expression to begin with.
[Bug middle-end/119537] ICE with [[gnu::assume]] vs computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119537
--- Comment #2 from Sam James ---
Clang crashes on this variant from the thread too:
```
#include
int main() {
goto *&&x;
typeof(({x: puts("hi");}) ) nope;
}
```
[Bug middle-end/119537] assume with statement expression and ("non-local") label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119537
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-03-29
Summary|ICE with [[gnu::assume]] vs |assume with statement
|computed goto |expression and
||("non-local") label
--- Comment #3 from Andrew Pinski ---
(In reply to Sam James from comment #0)
> This comes from lcamtuf: https://x.com/lcamtuf/status/1905745238666490269
https://hachyderm.io/@lcamtuf@infosec.exchange/114242359202024954 better link.
[Bug rtl-optimization/119538] New: FAIL: gcc.dg/torture/pr117938.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119538 Bug ID: 119538 Summary: FAIL: gcc.dg/torture/pr117938.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc -B/home/dave/gnu/gcc/o bjdir64/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr117938.c -fdi agnostics-plain-output -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftr acer -finline-functions -Wno-psabi --param=max-cse-insns=1 -lm -o ./pr117938.exe PASS: gcc.dg/torture/pr117938.c -O3 -fomit-frame-pointer -funroll-loops -fpeel -loops -ftracer -finline-functions -mlra (test for excess errors) Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/o bjdir64/hppa64-hp-hpux11.11/./libatomic/.libs::/home/dave/gnu/gcc/objdir64/gcc:/ home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libatomic/.libs:/home/dave/gnu/gcc/objdir64/gcc:/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs Execution timeout is: 300 spawn [open ...] FAIL: gcc.dg/torture/pr117938.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test Test only fails with this specific option. Doesn't fail with -mno-lra option.
[Bug tree-optimization/119536] [15 regression] Python fails to build (error: cannot tail-call: call invocation refers to locals)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119536 --- Comment #3 from Sam James --- I'll chuck this one into cvise.
[Bug target/119539] New: [15 Regression] FAIL: gcc.target/i386/apx-nf.c scan-assembler-times {nf} rol 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119539
Bug ID: 119539
Summary: [15 Regression] FAIL: gcc.target/i386/apx-nf.c
scan-assembler-times {nf} rol 4
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: haochen.jiang at intel dot com, liuhongt at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
On x86-64, r15-9029-geb26b667518c95 gave
FAIL: gcc.target/i386/apx-nf.c scan-assembler-times {nf} rol 4
with binutils master branch 20250329.
[Bug fortran/119540] New: [15 Regression] FAIL: gfortran.dg/reduce_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119540 Bug ID: 119540 Summary: [15 Regression] FAIL: gfortran.dg/reduce_1.f90 -O0 execution test Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: liuhongt at gcc dot gnu.org Target Milestone: --- Target: x86-64 On x86-64, r15-9029-geb26b667518c95 gave FAIL: gfortran.dg/reduce_1.f90 -O0 execution test FAIL: gfortran.dg/reduce_1.f90 -O1 execution test FAIL: gfortran.dg/reduce_1.f90 -O2 execution test FAIL: gfortran.dg/reduce_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/reduce_1.f90 -O3 -g execution test FAIL: gfortran.dg/reduce_1.f90 -Os execution test with -m32: Fortran runtime error: DIM in REDUCE intrinsic is less than 0 or greater than the rank of ARRAY Error termination. Backtrace: #0 0x804d3ba in ??? #1 0x804e12f in ??? #2 0xf793ef42 in ??? #3 0xf793f007 in ??? #4 0x8048387 in ??? #5 0x in ??? FAIL: gfortran.dg/reduce_1.f90 -O0 execution test
