[Bug fortran/119419] C prototype generation for functions returning C_FUNPTR incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119419 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-03-22 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug ada/118939] [14 Regression] ada: executable segfaults on arm-linux-gnueabi when assigning an access to controlled type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939 Adrian Bunk changed: What|Removed |Added CC||bunk at stusta dot de --- Comment #6 from Adrian Bunk --- (In reply to Matthias Klose from comment #5) > yes, there's the Debian patchset, but I'm usually not applying any > code-modifying patches on my own. Applying patch 0004-Ada-merge-all-timeval-and-timespec-definitions-and-c.diff patching file src/gcc/ada/Makefile.rtl Hunk #3 succeeded at 2850 (offset 7 lines). patching file src/gcc/ada/cal.c patching file src/gcc/ada/gcc-interface/Makefile.in patching file src/gcc/ada/libgnarl/a-exetim__posix.adb patching file src/gcc/ada/libgnarl/s-linux.ads patching file src/gcc/ada/libgnarl/s-linux__alpha.ads patching file src/gcc/ada/libgnarl/s-linux__android.ads patching file src/gcc/ada/libgnarl/s-linux__hppa.ads patching file src/gcc/ada/libgnarl/s-linux__loongarch.ads patching file src/gcc/ada/libgnarl/s-linux__mips.ads patching file src/gcc/ada/libgnarl/s-linux__riscv.ads patching file src/gcc/ada/libgnarl/s-linux__sparc.ads patching file src/gcc/ada/libgnarl/s-linux__x32.ads patching file src/gcc/ada/libgnarl/s-osinte__aix.adb patching file src/gcc/ada/libgnarl/s-osinte__aix.ads patching file src/gcc/ada/libgnarl/s-osinte__android.adb patching file src/gcc/ada/libgnarl/s-osinte__android.ads patching file src/gcc/ada/libgnarl/s-osinte__darwin.adb patching file src/gcc/ada/libgnarl/s-osinte__darwin.ads patching file src/gcc/ada/libgnarl/s-osinte__dragonfly.adb patching file src/gcc/ada/libgnarl/s-osinte__dragonfly.ads patching file src/gcc/ada/libgnarl/s-osinte__freebsd.adb patching file src/gcc/ada/libgnarl/s-osinte__freebsd.ads patching file src/gcc/ada/libgnarl/s-osinte__gnu.adb patching file src/gcc/ada/libgnarl/s-osinte__gnu.ads patching file src/gcc/ada/libgnarl/s-osinte__hpux-dce.adb patching file src/gcc/ada/libgnarl/s-osinte__hpux-dce.ads patching file src/gcc/ada/libgnarl/s-osinte__hpux.ads patching file src/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads patching file src/gcc/ada/libgnarl/s-osinte__linux.ads patching file src/gcc/ada/libgnarl/s-osinte__lynxos178.adb patching file src/gcc/ada/libgnarl/s-osinte__lynxos178e.ads patching file src/gcc/ada/libgnarl/s-osinte__posix.adb patching file src/gcc/ada/libgnarl/s-osinte__qnx.adb patching file src/gcc/ada/libgnarl/s-osinte__qnx.ads patching file src/gcc/ada/libgnarl/s-osinte__rtems.adb patching file src/gcc/ada/libgnarl/s-osinte__rtems.ads patching file src/gcc/ada/libgnarl/s-osinte__solaris.adb patching file src/gcc/ada/libgnarl/s-osinte__solaris.ads patching file src/gcc/ada/libgnarl/s-osinte__vxworks.adb patching file src/gcc/ada/libgnarl/s-osinte__vxworks.ads patching file src/gcc/ada/libgnarl/s-osinte__x32.adb patching file src/gcc/ada/libgnarl/s-qnx.ads patching file src/gcc/ada/libgnarl/s-taprop__hpux-dce.adb patching file src/gcc/ada/libgnarl/s-taprop__solaris.adb patching file src/gcc/ada/libgnarl/s-taprop__vxworks.adb patching file src/gcc/ada/libgnarl/s-tpopmo.adb patching file src/gcc/ada/libgnat/a-calcon.adb patching file src/gcc/ada/libgnat/a-calcon.ads patching file src/gcc/ada/libgnat/a-calend.adb patching file src/gcc/ada/libgnat/a-calend.ads patching file src/gcc/ada/libgnat/g-calend.adb patching file src/gcc/ada/libgnat/g-calend.ads patching file src/gcc/ada/libgnat/g-socket.adb patching file src/gcc/ada/libgnat/g-socthi.adb patching file src/gcc/ada/libgnat/g-socthi__vxworks.adb patching file src/gcc/ada/libgnat/g-sothco.ads patching file src/gcc/ada/libgnat/g-spogwa.adb patching file src/gcc/ada/libgnat/s-c_time.adb patching file src/gcc/ada/libgnat/s-c_time.ads patching file src/gcc/ada/libgnat/s-optide.adb patching file src/gcc/ada/libgnat/s-osprim__darwin.adb patching file src/gcc/ada/libgnat/s-osprim__posix.adb patching file src/gcc/ada/libgnat/s-osprim__posix2008.adb patching file src/gcc/ada/libgnat/s-osprim__rtems.adb patching file src/gcc/ada/libgnat/s-osprim__solaris.adb patching file src/gcc/ada/libgnat/s-osprim__unix.adb patching file src/gcc/ada/libgnat/s-osprim__x32.adb patching file src/gcc/ada/libgnat/s-parame.ads patching file src/gcc/ada/libgnat/s-parame__hpux.ads patching file src/gcc/ada/libgnat/s-parame__posix2008.ads patching file src/gcc/ada/libgnat/s-parame__vxworks.ads patching file src/gcc/ada/s-oscons-tmplt.c Applying patch 0009-Ada-select-64-bits-time-functions-from-GNU-libc-when.diff patching file src/gcc/ada/libgnarl/a-exetim__posix.adb patching file src/gcc/ada/libgnarl/s-osinte__gnu.ads patching file src/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads patching file src/gcc/ada/libgnarl/s-osinte__linux.ads patching file src/gcc/ada/libgnat/g-spogwa.adb patching file src/gcc/ada/libgnat/s-osprim__posix.adb patching file src/gcc/ada/libgnat/s-osprim__posix2008.adb patching file src/gcc/ada/s-oscons-tmplt.c Applying patch pr79724-revert.diff patching
[Bug tree-optimization/119424] New: memcpy->memset optimization should happen even for non-constant form of memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119424
Bug ID: 119424
Summary: memcpy->memset optimization should happen even for
non-constant form of memcpy
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
void g(int*,int s);
void f(int s)
{
//s = 222;
int buffer[222]={};
int buffer1[222];
__builtin_memcpy(&buffer1[0], &buffer[0], s*sizeof(int));
g(buffer1,s);
}
void f1(int s)
{
//s = 222;
int buffer[222]={};
int buffer1[222];
__builtin_memset(&buffer1[0], 0, s*sizeof(int));
g(buffer1,s);
}
```
We should be able to transform f to f1 but we current does not. If s was
constant, we could do it. In this case if s was `>= 222`, then it would be
undefined behavior so doing it always seems like a good idea.
This alone won't solve the testcase in PR 103483 but it might improve other
cases.
[Bug ada/118939] [14 Regression] ada: executable segfaults on arm-linux-gnueabi when assigning an access to controlled type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #8 from Sam James --- I can reproduce this without any patching on Gentoo. I'm working on some other bits but I'll provide a recipe and the information Eric asked for soon.
[Bug c++/119401] New: [15 regression] ICE when lambda is used as template argument in member function parameter type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119401
Bug ID: 119401
Summary: [15 regression] ICE when lambda is used as template
argument in member function parameter type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cmingyi01 at gmail dot com
Target Milestone: ---
The following C++20 code causes an ICE in trunk.
```
template
struct B {};
template
struct A {
static void f(B<[] {}>) {}
};
int main() {
A::f({});
}
```
Output:
```
: In instantiation of 'static void A::f(B< >) [with T =
int]':
:10:14: required from here
10 | A::f({});
| ~^~~~
:6:19: internal compiler error: in convert_nontype_argument, at
cp/pt.cc:7977
6 | static void f(B<[] {}>) {}
| ^~~~
0x291d555 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2934526 internal_error(char const*, ...)
???:0
0xacfad8 fancy_abort(char const*, int, char const*)
???:0
0xd152c3 coerce_template_parms(tree_node*, tree_node*, tree_node*, int, bool)
???:0
0xd27a69 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int)
???:0
0xd28f42 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd1c73d instantiate_decl(tree_node*, bool, bool)
???:0
0xd5688b instantiate_pending_templates(int)
???:0
0xbdcdd0 c_parse_final_cleanups()
???:0
0xe54128 c_common_parse_file()
???:0
```
See https://compiler-explorer.com/z/GKd834v8x.
[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #31 from Alexander Monakov --- I am certainly missing some interesting history here, because on one hand, I see that a.out uses call-pop combo in function prologue to find out current PC, and then uses %ebx-relative addressing in PIC code, but on the other hand, load addresses for a.out shared libraries were predetermined, so that seems redundant. (there wasn't lazy binding in a.out yet, was there?)
[Bug target/119361] RISC-V: x264 satd_4x4 stack spilling with mtune=generic-ooo for vls code but not on vla code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361 --- Comment #4 from Robin Dapp --- (In reply to Edwin Lu from comment #3) > I'm not familiar enough with how the two modes interact with each other but > I guess my question is, why do we have so many conversions between the two > modes? What's the benefit of using VLA modes for VLS codegen and vice versa? > It seems rather counterintuitive to me to have these two modes blend > together regardless of compiling for vla or vls. Right, it's not that we use real VLA modes for VLS. Part of the issue is that we repurpose the names of our usual VLA modes (like RVVM1SI) to mean VLS modes. In our backend we have a number of instances of riscv_v_ext_vector_mode_p () which basically pattern matches the mode name. If we see a "VLA name" we go the VLA codegen route instead of the possibly simpler VLS one. At some point we also have VLS subregs of "VLA-name but actually VLS modes". This shouldn't be a problem because the middle end handles this correctly as long as we gave it the proper info but all in all it just doesn't really feel right. The difference between "VLA with minimum zvl" and "-mrvv-vector-bits = zvl == VLA with minimum zvl and maximum zvl" is that the separation in mode names is clear in the former but not the latter. In total it's not that bad but needs some work in the backend to get it right.
[Bug c++/119401] [15 regression] ICE when lambda is used as template argument in member function parameter type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119401 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||nshead at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Marek Polacek --- Started with r15-7202: commit 8990070b4297b913025d564293f97c0440622976 Author: Nathaniel Shead Date: Thu Jan 23 19:22:04 2025 +1100 c++: Fix mangling of otherwise unattached class-scope lambdas [PR118245]
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 114292, which changed state. Bug 114292 Summary: [12 Regression] ICE with a generic (templated) lambda capturing a constant for VLA allocation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 --- Comment #16 from Tomasz Kamiński --- The changes are also required for .
[Bug rust/116225] Rust test failures with -D_GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116225 Sam James changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |15.0 --- Comment #4 from Sam James --- Fixed between 15th and 19th March and there's a CI job for this in the gccrs repo now too.
[Bug target/119291] [13/14/15 regression] wrong code at -O{2, 3} with "-fno-thread-jumps" on x86_64-linux-gnu since r13-793-g8fb94fc6097c0a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291 --- Comment #7 from Andrew Pinski --- Created attachment 60839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60839&action=edit testcase that aborts instead of infinite loop This testcase makes it easier to put into the testsuite. It aborts with `-O3 -fno-thread-jumps ` but works at all other optimization levels.
[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #32 from Ard Biesheuvel ---
Franz, given that you are building your own compiler, mind checking whether the
below fixes the issue for you?
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -23154,6 +23154,8 @@
if (flag_nop_mcount || !strcmp (target, "nop"))
/* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1) */
fprintf (file, "1:" ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
+ else if (flag_pic && flag_plt)
+fprintf (file, "1:\tcall\t%s@PLT\n", target);
else
fprintf (file, "1:\tcall\t%s\n", target);
}
@@ -23317,7 +23319,7 @@
break;
case CM_SMALL_PIC:
case CM_MEDIUM_PIC:
- if (!ix86_direct_extern_access)
+ if (!flag_plt)
{
if (ASSEMBLER_DIALECT == ASM_INTEL)
fprintf (file, "1:\tcall\t[QWORD PTR %s@GOTPCREL[rip]]\n",
[Bug fortran/119403] New: Typo in Interface mismatch in dummy procedure at %L conflichts with %L: %s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119403 Bug ID: 119403 Summary: Typo in Interface mismatch in dummy procedure at %L conflichts with %L: %s Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- There is a typo in word "conflichts" in fortran/interface.cc:2497 2496 gfc_error_opt (0, "Interface mismatch in dummy procedure " 2497"at %L conflichts with %L: %s", &actual->where, 2498&formal->declared_at, err);
[Bug target/119291] [12/13/14/15 regression] wrong code at -O{2,3} on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291 Andrew Pinski changed: What|Removed |Added Attachment #60840|0 |1 is obsolete|| --- Comment #10 from Andrew Pinski --- Created attachment 60841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60841&action=edit testcase worked failed starting in GCC 9
[Bug translation/119404] New: Possible typo in: Usa LRA for reload instead of the old reload framework
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119404 Bug ID: 119404 Summary: Possible typo in: Usa LRA for reload instead of the old reload framework Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- I see this message in config/m68k/m68k.opt:151 > Usa LRA for reload instead of the old reload framework. This option is > experimental, and it may be removed in future versions of the compiler. See https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/m68k.opt;h=35f86ba11ff0395178ebfed30472114dfb3f9f38;hb=HEAD#l149 Is "Usa LRA" a typo? If not, can you please explain what it means?
[Bug target/119291] [12/13/14/15 regression] wrong code at -O{2,3} on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291 Andrew Pinski changed: What|Removed |Added Known to work|11.5.0 |8.5.0 Known to fail|12.1.0 |9.1.0 Keywords|needs-bisection | --- Comment #11 from Andrew Pinski --- (In reply to Andrew Pinski from comment #10) > Created attachment 60841 [details] > testcase failed starting in GCC 9 I am 99% sure this will bisect to a patch to tree-ssa-coalesce.c. I don't think it is worth bisecting at this point either.
[Bug c/119405] New: Missed FMA optimization for C code present in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119405
Bug ID: 119405
Summary: Missed FMA optimization for C code present in C++
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.gr...@tu-dresden.de
Target Milestone: ---
In a third-party library a test is failing on AMD Rome (Zen2) that I traced
ultimately to a function doing a simple quaternion multiplication.
Similar code is present in a C and a C++ file that are later linked together,
reducing that to exactly the same code I see an FMA in the C++ code but not in
C.
The reduced code is:
```
void mjuu_mulquat(double* res, const double* qa, const double* qb) {
double tmp[4] = {
qa[0]*qb[0] - qa[1]*qb[1] - qa[2]*qb[2] - qa[3]*qb[3],
qa[0]*qb[1] + qa[1]*qb[0] + qa[2]*qb[3] - qa[3]*qb[2],
qa[0]*qb[2] - qa[1]*qb[3] + qa[2]*qb[0] + qa[3]*qb[1],
qa[0]*qb[3] + qa[1]*qb[2] - qa[2]*qb[1] + qa[3]*qb[0]
};
res[0] = tmp[0];
res[1] = tmp[1];
res[2] = tmp[2];
res[3] = tmp[3];
}
```
Compiling it with `-O3 -std=c++11 -mavx2 -mfma` and `-O3 -std=c11 -mavx2
-mfma` shows vfmadd132pd vfnmadd132pd in C++ not present in C. Comparison:
https://godbolt.org/z/TsYqcssnM
I don't see why the code would optimize differently in those cases as I'd
expect the optimizer gets the same input which is seemingly not the case.
[Bug fortran/119349] [15 Regression] polymorphic array dummy argument with function result actual argument in elemental function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349 --- Comment #8 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:0f344846a62c8863375909d8d6b435b4b5fd35a0 commit r15-8481-g0f344846a62c8863375909d8d6b435b4b5fd35a0 Author: Andre Vehreschild Date: Thu Mar 20 13:37:21 2025 +0100 Fortran: Fix double free on polymorphic array dummy argument [PR119349] Calling elemental routines with polymorphic formals leads to generation of a temporary polymorphic variable and code for its deallocation. Sourcing this element from an array constructor the latter now is prevented from generating a second deallocation. PR fortran/119349 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_procedure_call): Prevent deallocation of array temporary for polymorphic temporary argument. gcc/testsuite/ChangeLog: * gfortran.dg/class_79.f90: New test.
[Bug target/119404] Possible typo in: Usa LRA for reload instead of the old reload framework
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119404 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target||m68k Component|translation |target Last reconfirmed||2025-03-21 --- Comment #1 from Andrew Pinski --- >Is "Usa LRA" a typo? Yes it should be "Use LRA ..."
[Bug libgcc/119396] libgcc: Shared objects are being built for target that doesn't support shared libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119396 --- Comment #2 from Georg-Johann Lay --- What I have already tried is to set SHLIB_LINK := in t-avr, which should imply enable_shared=no. But it had no effect. Also I don't know where SHLIB_LINK should be set. In the top-level configure.ac ? (C++ shared libs also wouln't make sense since there isn't even a dynamic linker for avr).
[Bug target/119410] New: 5% slowdown of 510.parest_r on Intel Ice Lake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119410 Bug ID: 119410 Summary: 5% slowdown of 510.parest_r on Intel Ice Lake Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=796.457.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=801.457.0 there was a 5% exec time slowdown of the 510.parest_t SPEC 2017 benchmark between commits r15-7978-g7efe3aa9b5d4d7 r15-8017-g4e6967aba1aaa9 when run with -Ofast -march=native, with and withou -flto on an Intel Ice Lake (3rd generation Xeon) machine. This is *not* a regression against GCC 14. See the comparison here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.4=1093.457.0&plot.5=801.457.0&; https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.4=1097.457.0&plot.5=796.457.0&; Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/119399] Overlap check in vectorized code may invoke UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399 Richard Biener changed: What|Removed |Added Last reconfirmed||2025-03-21 Keywords||wrong-code Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #1 from Richard Biener --- Confirmed. We'd have to do q < p || (unsigned)(q+4) - (unsigned)p > 8 or sth like this I think. Possibly not relevant on 64bit virtual address space targets, but also obviously OS dependent (and possibly dependent on whether we deal with user or kernel address space or a freestanding env.) Alternatively we can document additional restrictions on object placement, though I think there was 32bit x86 kernel support with more than half of the virtual address space available to userland.
[Bug rtl-optimization/101995] [12/13/14/15 Regression] regression built-in memset missed-optimization arm -Os since r9-3594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #16 from Richard Earnshaw ---
Still present.
Perhaps more significantly (and possibly related)
class x
{
public:
x ();
int func ();
private:
int a;
};
int g ()
{
x b;
return b.func();
}
generates:
g():
push{lr}
sub sp, sp, #12
add r0, sp, #4
bl x::x() [complete object constructor]
add r0, sp, #4 // Redundant - ABI returns 'this' from a
constructor
bl x::func()
add sp, sp, #12
pop {pc}
[Bug fortran/119380] [12,13,14,15] Free of procedure pointer components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380 --- Comment #6 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:a5c69abf1384ec6163cd5e14146e8b3876e8b95c commit r15-8642-ga5c69abf1384ec6163cd5e14146e8b3876e8b95c Author: Andre Vehreschild Date: Fri Mar 21 09:13:29 2025 +0100 Fortran: Fix freeing procedure pointer components [PR119380] PR fortran/119380 gcc/fortran/ChangeLog: * trans-array.cc (structure_alloc_comps): Prevent freeing of procedure pointer components. gcc/testsuite/ChangeLog: * gfortran.dg/proc_ptr_comp_54.f90: New test.
[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #30 from Alexander Monakov --- Sorry, sent too soon: a.out had the concept of PLT as well as GOT: https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.c?id=c98f874233428d7e6ba83def7842fd703ac0ddf1#n820
[Bug fortran/119380] [12,13,14,15] Free of procedure pointer components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380 Andre Vehreschild changed: What|Removed |Added Status|NEW |WAITING Summary|[12,13,14,15] Associate |[12,13,14,15] Free of |malloc error on selector|procedure pointer |with allocatable and|components |procedure pointer | |components | Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #5 from Andre Vehreschild --- The bug has nothing to do with associate specifically, but will occur on regular assign, too. GFortran missed out on not freeing procedure pointer components. The patch here: https://gcc.gnu.org/pipermail/fortran/2025-March/061937.html prevents that free. It may be worth to discuss, whether the procedure pointer component should be nullified only, but given that the whole type is going to be freed, I see no need yet. Awaiting review.
[Bug middle-end/117811] [12/13/14/15 Regression] bad code for conditional right shift with autovec and neon since r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811 --- Comment #21 from Richard Earnshaw --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678597.html
[Bug c++/114292] [12/13 Regression] ICE with a generic (templated) lambda capturing a constant for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292
--- Comment #14 from GCC Commits ---
The releases/gcc-13 branch has been updated by Simon Martin
:
https://gcc.gnu.org/g:65e998d172e006cdf0dd4d58f83784a5fed61fc5
commit r13-9441-g65e998d172e006cdf0dd4d58f83784a5fed61fc5
Author: Simon Martin
Date: Fri Mar 21 07:02:20 2025 +0100
c++: Don't prune constant capture proxies only used in array dimensions
[PR114292]
We currently ICE upon the following valid (under -Wno-vla) code
=== cut here ===
void f(int c) {
constexpr int r = 4;
[&](auto) { int t[r * c]; }(0);
}
=== cut here ===
When parsing the lambda body, and more specifically the multiplication,
we mark the lambda as LAMBDA_EXPR_CAPTURE_OPTIMIZED, which indicates to
prune_lambda_captures that it might be possible to optimize out some
captures.
The problem is that prune_lambda_captures then misses the use of the r
capture (because neither walk_tree_1 nor cp_walk_subtrees walks the
dimensions of array types - here "r * c"), hence believes the capture
can be pruned... and we trip on an assert when instantiating the lambda.
This patch changes cp_walk_subtrees so that (1) when walking a
DECL_EXPR, it also walks the DECL's type, and (2) when walking an
INTEGER_TYPE and processing a template declaration, it also walks its
TYPE_{MIN,MAX}_VALUE.
PR c++/114292
gcc/cp/ChangeLog:
* tree.cc (cp_walk_subtrees): Walk the type of DECL_EXPR
declarations, as well as the TYPE_{MIN,MAX}_VALUE of
INTEGER_TYPEs for template declarations.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/lambda-ice4.C: New test.
(cherry picked from commit f86d274ab76fdd89d7afd9b2eab28f3a61749cfb)
[Bug ada/105212] -gnatwu gives false error message for certain arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105212 Honki Tonk changed: What|Removed |Added Version|13.1.0 |14.2.0 --- Comment #3 from Honki Tonk --- The error still occurs with version 14.2.
[Bug libstdc++/119409] New: should not include all of and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119409 Bug ID: 119409 Summary: should not include all of and Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Currently the header does: #if __cplusplus >= 201703L # if _GLIBCXX_HOSTED # include # include # include # endif # include // std::search #endif This means that all feature test macros defined by are being defined by . It would be better if we include internal headers instead, so that we don't "leak" feature test macros for containers into So something like: #if __cplusplus >= 201703L # if _GLIBCXX_HOSTED # include # include # include # include # endif # include // std::search #endif
[Bug c++/119405] C++ for non gnu mode should set -ffp-contract=off just like C non-gnu modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119405 --- Comment #7 from Jonathan Wakely --- We already have the -fexcess-precision=standard difference between gnu++ and c++ modes. That only changed recently for C++, which might be why fp-contract isn't the same between C and C++.
[Bug target/119291] [13/14/15 regression] wrong code at -O{2, 3} with "-fno-thread-jumps" on x86_64-linux-gnu since r13-793-g8fb94fc6097c0a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291 Andrew Pinski changed: What|Removed |Added Attachment #60839|0 |1 is obsolete|| --- Comment #8 from Andrew Pinski --- Created attachment 60840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60840&action=edit testcase that fails at -O2 since GCC 12
[Bug ipa/119376] [15 Regression] musttail does not get dropped after inlining?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:37ae2e055687a22974d7bcb9e618f258fa49ab1a commit r15-8492-g37ae2e055687a22974d7bcb9e618f258fa49ab1a Author: Jakub Jelinek Date: Fri Mar 21 12:17:01 2025 +0100 inliner: Silently drop musttail flag on calls during inlining unless the inlined routine was musttail called [PR119376] As discussed in the PR, some packages fail to build because they use musttail attribute on calls in functions which we inline, and if they are inlined into a middle of the function, that results in an error because we have a musttail call in the middle of a function and so it can't be tail called there. Now, guess the primary intent of the musttail attribute is ensuring we don't get an extra stack frame in the backtrace. Inlining itself removes one extra stack frame from the backtrace as well (sure, not counting virtual backtraces in gdb), so I think erroring out on that is unnecessary. Except when we are inlining a musttail call which has musttail calls in it, in that case we are being asked to remove 2 stack frames from the backtrace, inlining removes one, so we need to keep musttail on the calls so that another stack frame is removed through a tail call. The following patch implements that, keeping previous behavior when id->call_stmt is NULL (i.e. when versioning/cloning etc.). 2025-03-21 Jakub Jelinek PR ipa/119376 * tree-inline.cc (remap_gimple_stmt): Silently clear gimple_call_must_tail_p on inlined call stmts if id->call_stmt is a call without that flag set. * c-c++-common/musttail26.c: New test.
[Bug c/119408] New: LoongArch: Q Suffix for __float128 Literals Not Supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
Bug ID: 119408
Summary: LoongArch: Q Suffix for __float128 Literals Not
Supported
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: wszqkzqk at qq dot com
Target Milestone: ---
The GCC manual explicitly states that __float128 literals require the Q suffix.
According to [GCC Manual: Floating
Types](https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html?spm=a2ty_o01.29997173.0.0.7c72c921e8gZ5X):
> Use a suffix ‘q’ or ‘Q’ for __float128.
> __float128 is available on [...] LoongArch [...] as an alias for _Float128.
This means platforms including LoongArch that support `__float128` should
support `Q` suffix in 128-bit float point literals. However, LoongArch's GCC
implementation contradicts this:
* The Q suffix (e.g., `1.0Q`) fails with `error: unsupported non-standard
suffix on floating constant`,
* While the GNU-extension f128 suffix (e.g., `1.0f128`) works for `_Float128`.
This inconsistency breaks code using `__float128` literals. (I found it by
build sleef on LoongArch64 platform).
Tested on Arch Linux for Loong64 with:
* gcc 14.2.1
* demo:
```c
#include
int main() {
__float128 a = 1.Q;
}
```
[Bug cobol/119390] cobol compiler crashes with buffer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119390
--- Comment #3 from Andreas Schwab ---
#9 lang_specific_driver (in_decoded_options=0x7fffd970,
in_decoded_options_count=0x7fffd97c,
in_added_libraries=) at ../../gcc/cobol/gcobolspec.cc:510
510 strcpy(ach, decoded_options[i].arg);
(gdb) ptype ach
type = char [128]
(gdb) ptype decoded_options
type = struct cl_decoded_option {
size_t opt_index;
const char *warn_message;
const char *arg;
const char *orig_option_with_args_text;
const char *canonical_option[4];
size_t canonical_option_num_elements;
long value;
long mask;
int errors;
} *
(gdb) p decoded_options[i].arg
$1 = 0x7fffe169
"/home/abuild/rpmbuild/BUILD/gcc15-testresults-15.0.1+git8460-build/gcc-15.0.1+git8460/gcc/testsuite/cobol.dg/group1/check_88.cob"
[Bug libstdc++/119409] should not include all of and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119409 --- Comment #1 from Jonathan Wakely --- Similarly: include/std/chrono:# include include/std/chrono:# include include/std/chrono:# include include/std/flat_map:#include // not_fn include/std/flat_map:#include // views::zip include/std/flat_map:#include include/std/flat_set:#include // not_fn include/std/flat_set:#include Currently not_fn is only in but we could split that header up into smaller pieces. And we'll probably want to split up at some point, so that we can use individual adaptors in library internals without having to compile all of them every time.
[Bug fortran/119349] [15 Regression] polymorphic array dummy argument with function result actual argument in elemental function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349 Andre Vehreschild changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/119405] Missed FMA optimization for C code present in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119405 --- Comment #2 from Andrew Pinski --- If you used -std=gnu11, -std=gnu++11 then the setting would be -ffp-contract=on
[Bug d/118545] d: Not all language options get a url in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118545 --- Comment #1 from GCC Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:47822ef8f1b03ab7124aba694709825a93897994 commit r15-8477-g47822ef8f1b03ab7124aba694709825a93897994 Author: Iain Buclaw Date: Fri Mar 21 00:28:45 2025 +0100 d: Fix quoted command-line options to match lang.opt [PR118545] It was noticed that not all D language options get a url in diagnostics. These have been checked and fixed as necessary. PR d/118545 gcc/d/ChangeLog: * d-lang.cc (d_handle_option): Adjust quoted options.
[Bug c++/119405] Missed FMA optimization for C code present in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119405 --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902#c36 So this is by design. Except maybe C++ front-end should change too.
[Bug c++/119405] C++ for non gnu mode should set -ffp-contract=off just like C non-gnu modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119405 --- Comment #5 from Andrew Pinski --- I am going to leave this open for a C++ front-end person to decide if they want to make the change to be similar to the C front-end here. BUT the C front-end is doing it by design. If you want something different then you can either use -ffp-contract=on or -ffp-contract=fast or -std=gnu11 instead.
[Bug c++/119405] Missed FMA optimization for C code present in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119405 --- Comment #4 from Andrew Pinski --- Setting to =off for -std=c* (and not -std=c++*) was done in r0-126303-g6dbe09581a1349.
[Bug c++/119405] Missed FMA optimization for C code present in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119405 Andrew Pinski changed: What|Removed |Added Component|c |c++ --- Comment #1 from Andrew Pinski --- The difference is -std=c11 sets -ffp-contract=off while -std=c++11 does not.
[Bug fortran/119380] [12,13,14,15] Associate malloc error on selector with allocatable and procedure pointer components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380 --- Comment #4 from Andre Vehreschild --- (In reply to anlauf from comment #1) > Is the known-to-fail list correct? > I do not see failures for 11- and 12-releases. > > The dump tree also changes only between 12 and 13. > To me it looks rather like a 13/14/15 regression. I misunderstood this as a regression and looked for a known good version of v 11 branching off of master. Unfortunately that branch point 250f234988b6231669a720c52101d3686d645072 also fails the test. I therefore errorneously assumed that all versions are affected. I tried to add a 11-version to the known to fail list and 11.1.0 was the first one accepted. The other versions I took from Damian's report, trusting he has tested them.
[Bug cobol/119241] cobol Front end uses host floating point (128b) support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241 Richard Biener changed: What|Removed |Added Attachment #60834|0 |1 is obsolete|| --- Comment #26 from Richard Biener --- Created attachment 60842 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60842&action=edit functional patch with less bugs
[Bug cobol/119241] cobol Front end uses host floating point (128b) support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241 --- Comment #25 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a62893d71c5f48fd7780957e1ad1a4f38f351728 commit r15-8482-ga62893d71c5f48fd7780957e1ad1a4f38f351728 Author: Richard Biener Date: Wed Mar 19 15:09:03 2025 +0100 make sources coretypes.h and tree.h clean The following removes HOWEVER_GCC_DEFINES_TREE and the alternate definition of tree from symbols.h and instead ensures that both coretypes.h and tree.h are included where required. This required putting GCCs own 'NONE' in a scoped enum (see separate patch) and renaming the cobol use of UNSIGNED, SIGNED and BLOCK which conflict with enums from tree.h. There's a few things in conflict with options.h defines, notably cobol_dialect and cobol_exceptions but also yy_flex_debug (wherever that comes from). I've chosen to simply #undef those where appropriate. I've refrained from putting the coretypes.h and tree.h includes in cobol-system.h since not all files require this. This helps in making use of real.h instead of using _Float128. PR cobol/119241 gcc/cobol/ * symbols.h: Do not typedef tree. * cdf.y: Include coretypes.h and tree.h. * symbols.cc: Likewise. * symfind.cc: Likewise. * util.cc: Likewise. * parse.y: Include coretypes.h and tree.h where appropriate. Rename BLOCK to COB_BLOCK, SIGNED to COB_SIGNED, UNSIGNED to COB_UNSIGNED. * scan.l: Likewise. * token_names.h: Likewise. * cobol1.cc: Do not define HOWEVER_GCC_DEFINES_TREE. * except.cc: Likewise. * genapi.cc: Likewise. * gengen.cc: Likewise. * genmath.cc: Likewise. * genutil.cc: Likewise. * structs.cc: Likewise.
[Bug target/119291] [13/14/15 regression] wrong code at -O{2, 3} with "-fno-thread-jumps" on x86_64-linux-gnu since r13-793-g8fb94fc6097c0a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291 --- Comment #6 from Andrew Pinski --- Note disabling combine (-fdisable-rtl-combine) works around the issue. So we know what is coming out of expand is correct.
[Bug target/119235] Argument pointer survives LRA with -m31 -mzarch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119235 --- Comment #1 from GCC Commits --- The master branch has been updated by Stefan Schulze Frielinghaus : https://gcc.gnu.org/g:2b383ae2a6e5fc0530bfd8b86ad0e6b27e760bd2 commit r15-8483-g2b383ae2a6e5fc0530bfd8b86ad0e6b27e760bd2 Author: Stefan Schulze Frielinghaus Date: Fri Mar 21 10:29:19 2025 +0100 s390: Accept only Pmode for registers AP/FP/RA [PR119235] gcc/ChangeLog: PR target/119235 * config/s390/s390.cc (s390_hard_regno_mode_ok): Accept only Pmode for registers AP/FP/RA.
[Bug c++/119405] C++ for non gnu mode should set -ffp-contract=off just like C non-gnu modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119405 --- Comment #6 from Richard Biener --- IMO the different behavior between gnu and non-gnu is odd.
[Bug tree-optimization/119399] Overlap check in vectorized code may invoke UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399 --- Comment #2 from Richard Biener --- Note the possible UB is in the POINTER_DIFF_EXPR _25 = p_12(D) - _7 which we should arguably not use but instead use an integer type difference when different objects are involved. Still the actual alias check looks prone to overflow issues since we do not distinguish before/after placement.
[Bug fortran/119406] New: Typo in Index variable %qs at %L cannot be specified in alocality-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119406
Bug ID: 119406
Summary: Typo in Index variable %qs at %L cannot be specified
in alocality-spec
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
Missing space in fortran/resolve.cc:8217
(https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/fortran/resolve.cc;h=b9c469a5beca8014ba2a832d77c83109b626a233;hb=HEAD#l8218).
8218 gfc_error ("Index variable %qs at %L cannot be specified in a"
8219"locality-spec", sym->name, &expr->where);
The resulting string is "Index variable %qs at %L cannot be specified in
alocality-spec" in PO file.
[Bug ipa/119376] [15 Regression] musttail does not get dropped after inlining?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:589c94da22ec71fe8518878e801e88b05deffe18 commit r15-8493-g589c94da22ec71fe8518878e801e88b05deffe18 Author: Jakub Jelinek Date: Fri Mar 21 12:17:45 2025 +0100 fnsplit: Set musttail call during function splitting if there are musttail calls [PR119376] The just posted inliner patch can regress musttail calls if we perform function splitting and then inline the outlined body back into the original (or inline both the small function and outlined large body into something else). If there are any musttail calls, I think we need to call the outlined body using a musttail call, so that the inliner will preserve musttail attributes in the body. 2025-03-21 Jakub Jelinek PR ipa/119376 * ipa-split.cc (split_function): Call gimple_call_set_must_tail on the call to outlined partition if has_musttail and !add_tsan_func_exit. * g++.dg/opt/musttail1.C: New test. --- Comment #10 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:28caa267dc757d80ffe37d638d981d3572c164ae commit r15-8494-g28caa267dc757d80ffe37d638d981d3572c164ae Author: Jakub Jelinek Date: Fri Mar 21 12:18:35 2025 +0100 icf: Punt for musttail call flag differences in ICF [PR119376] The following testcase shows we were ignoring musttail flags on calls when deciding if two functions are the same. That can result in problems in both directions, either we silently lose musttail attribute because there is a similar function without it earlier and then we e.g. don't diagnose if it can't be tail called or don't try harder to do a tail call, or we get it even in functions which didn't have it before. The following patch for now just punts if it differs. Perhaps we could just merge it and get musttail flag if any of the merged functions had one in such position, but it feels to me that it is now too late in GCC 15 cycle to play with this. 2025-03-21 Jakub Jelinek PR ipa/119376 * ipa-icf-gimple.cc (func_checker::compare_gimple_call): Return false for gimple_call_must_tail_p mismatches. * c-c++-common/musttail27.c: New test.
[Bug c/119408] LoongArch: Q Suffix for __float128 Literals Not Supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408 --- Comment #1 from Richard Biener --- Q is an extension, 1.1f128 should work. The extension is enabled only for some platforms.
[Bug middle-end/117811] [12/13/14/15 Regression] bad code for conditional right shift with autovec and neon since r12-897-gde56f95afaaa22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811 --- Comment #22 from Christophe Lyon --- Bootstrap on arm-linux-gnueabihf passes, 'make check' too. Sorry for the delay, I was trying to understand an ICE gcc.target/arm/mve/general/preserve_user_namespace_1.c after I bootstrapped with your patch. The ICE is not present in my reference CI build, but it's still there in my manual build after reverting your patch.
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2025-03-21
--- Comment #3 from Richard Biener ---
Confirmed. We have
Breakpoint 5, psa_FldBlob (var=0x77dd01f8)
at ../../src/gcc/gcc/cobol/genapi.cc:4078
4078 TREE_CONSTANT(array_constructor) = 1;
(gdb) p *var
$1 = {offset = 0, type = FldBlob, usage = FldInvalid, attr = 128, parent = 0,
our_index = 81, level = 0, occurs = {bounds = {lower = 0, upper = 0},
depending_on = 0, nkey = 0, keys = 0x0, indexes = {nfield = 0,
fields = 0x0}}, line = 0,
name = "_DECLARATIVE_BLOB1_", '\000' , file = 0,
linkage = {optional = false, crv = by_default_e}, data = {memsize = 352,
capacity = 352, digits = 0, rdigits = 0, initial = 0x54e6990 "\003",
picture = 0x54e6990 "\003", etc_type = cbl_field_data_t::value_e, etc = {
val88 = {false_value = 0x76853030, domain = 0x0},
upsi_mask = 0x76853030, value = },
time_func = 0x0}, var_decl_node = , data_decl_node = ,
literal_decl_node = }
so var->data.capacity == 352 but var->data.initial[] appears short.
Whether that's supposed to be longer (zero-filled?) is unclear. I'd expect
that FldBlob might include '\0'.
[Bug target/119408] LoongArch: Q Suffix for __float128 Literals Not Supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408 Jakub Jelinek changed: What|Removed |Added Component|c |target CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- If a backend wants to support that suffix, it needs to define TARGET_C_MODE_FOR_SUFFIX hook and handle it there. See aarch64/i386/ia64/pa/rs6000 backends which do that.
[Bug c/119408] LoongArch: Q Suffix for __float128 Literals Not Supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408 --- Comment #2 from Zhou Qiankang --- (In reply to Richard Biener from comment #1) > Q is an extension, 1.1f128 should work. The extension is enabled only > for some platforms. But this extension (__flaot128) actually enables on LoongArch64 platform.
[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #34 from Alexander Monakov --- We have -mcmodel=kernel already, which is incompatible with -fpic. Ard, where is -fpic in the kernel context coming from? Kernel's top-level Makefile passes -fno-PIE, and arch/x86/Makefile passes -mcmodel=kernel. What is the scenario your r14-811 patch was dealing with?
[Bug cobol/119414] New: cobol driver unconditionally adds platform-specific command line options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 Bug ID: 119414 Summary: cobol driver unconditionally adds platform-specific command line options. Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- The following options are added unconditionally by gcobolspec.cc and either need conditionalising or removing: (plus some comment as to why they are required). 1. -rdynamic (this might not be supported on all targets). What is this needed for? perhaps the library is using some symbol that the executable is meant to export? perhaps (on targets that would otherwise hide it) we can explicitly export the necessary symbol(s). This will effectively (as I understand it) cause the exe to export all symbols - which can cause issues if it is statically linked with some libraries (e.g. libstdc++). 2. --allow-multiple-definitions (not supported by all linkers) Why do we need to allow multiple definitions? (in any event, iff it is needed, then we need some configuration changes to use whatever option the target's linker supports, if any). 3. pic/PIC options. (these are target-specific in general). It's not clear why the gcobol driver needs to be concerned with these - typically the target-specific specs processing handles this.
[Bug target/119408] LoongArch: Q Suffix for __float128 Literals Not Supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |14.3 --- Comment #5 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #4) > The reason is we already added __float128 (at r14-3635)
[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #38 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #37)
> Yes, we can drop -mcmodel=kernel, and use -mcmodel=small instead. This is
> why I'm not keen on relying on that - it is ill-defined and there is really
> no need to have this special case. In the kernel, we are trying to move away
> from all the special sauce in the toolchain - x86 especially is affected by
> this, whereas arm64 and other architectures just use -mcmodel=small. The
> primary sticking point is the relative cost of RIP-relative LEA vs 32-bit
> absolute MOV but that gap appears to have been closing in recent designs.
There's a couple places where GCC restricts offsets differently for
-mcmodel=kernel vs. -mcmodel=small in the x86 backend. It's been determined it
doesn't matter? How so?
https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/predicates.md#n239
> I'm not sure what that would solve. When linking the kernel, all
> R_X86_64_PLT32 can be resolved directly, and so there is never the need for
> a PLT in practice. The compiler does not have to care about this
> distinction. Relaxing a CALL via a PLT into a direct one is much easier than
> relaxing a GOT based data reference into a direct one.
It's not just about the calls. On x86-64 it's less pronounced, but on arm64
telling the compiler up front that everything ends up in the final executable
can improve codegen when referencing extern variables, for instance:
//__attribute__((visibility("hidden")))
extern int a[];
int f(void)
{
return a[1];
}
gcc -O2 -fpie gets you
f:
adrp x0, 0 <_GLOBAL_OFFSET_TABLE_>
R_AARCH64_ADR_PREL_PG_HI21 _GLOBAL_OFFSET_TABLE_
ldrx0, [x0]
R_AARCH64_LD64_GOTPAGE_LO15 a
ldrw0, [x0, #4]
ret
and with the attribute uncommented, emulating what -fstatic-pie would do:
f:
adrp x0, 0
R_AARCH64_ADR_PREL_PG_HI21 a+0x4
ldrw0, [x0]
R_AARCH64_LDST32_ABS_LO12_NC a+0x4
ret
[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #39 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #38)
> (In reply to Ard Biesheuvel from comment #37)
> > Yes, we can drop -mcmodel=kernel, and use -mcmodel=small instead. This is
> > why I'm not keen on relying on that - it is ill-defined and there is really
> > no need to have this special case. In the kernel, we are trying to move away
> > from all the special sauce in the toolchain - x86 especially is affected by
> > this, whereas arm64 and other architectures just use -mcmodel=small. The
> > primary sticking point is the relative cost of RIP-relative LEA vs 32-bit
> > absolute MOV but that gap appears to have been closing in recent designs.
>
> There's a couple places where GCC restricts offsets differently for
> -mcmodel=kernel vs. -mcmodel=small in the x86 backend. It's been determined
> it doesn't matter? How so?
> https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/predicates.md#n239
>
PIC code can run anywhere, so it can also run in the top 2 GB of the 64-bit
address space, which is what the kernel code model is limited to.
> > I'm not sure what that would solve. When linking the kernel, all
> > R_X86_64_PLT32 can be resolved directly, and so there is never the need for
> > a PLT in practice. The compiler does not have to care about this
> > distinction. Relaxing a CALL via a PLT into a direct one is much easier than
> > relaxing a GOT based data reference into a direct one.
>
> It's not just about the calls. On x86-64 it's less pronounced, but on arm64
> telling the compiler up front that everything ends up in the final
> executable can improve codegen when referencing extern variables, for
> instance:
>
> //__attribute__((visibility("hidden")))
> extern int a[];
>
> int f(void)
> {
> return a[1];
> }
>
> gcc -O2 -fpie gets you
>
> f:
> adrp x0, 0 <_GLOBAL_OFFSET_TABLE_>
> R_AARCH64_ADR_PREL_PG_HI21 _GLOBAL_OFFSET_TABLE_
> ldr x0, [x0]
> R_AARCH64_LD64_GOTPAGE_LO15 a
> ldr w0, [x0, #4]
> ret
>
> and with the attribute uncommented, emulating what -fstatic-pie would do:
>
> f:
> adrp x0, 0
> R_AARCH64_ADR_PREL_PG_HI21 a+0x4
> ldr w0, [x0]
> R_AARCH64_LDST32_ABS_LO12_NC a+0x4
> ret
In Linux, we don't even bother with PIC codegen, even though we link with -pie.
The non-PIC AArch64 small code model uses PC-relative references for code and
data.
I do agree that it would be better for this behavior to be explicit, so I'd
switch Linux to it if it ever appeared. But only to keep the existing behavior.
We do use hidden visibility in Linux (using #pragma) in some places, when
building PIC code that must not ever use absolute references (which makes the
use of a GOT impossible)
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-03-21 Depends on||111055 --- Comment #3 from Jonathan Wakely --- (In reply to 康桓瑋 from comment #0) > Bug 118156 fixes the non-common range issue, and one of the new branches is: > > else if constexpr (ranges::common_range<_Rg>) > __it = _M_cont.insert(_M_cont.end(), ranges::begin(__rg), > ranges::end(__rg)); We have a patch sent to the mailing list that will add std::deque::insert_range so I think we could use that here instead of insert (and that would work for non-common ranges too). Using insert_range wasn't an option until now, because not all our sequence containers supported insert_range. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 [Bug 111055] [C++23] Implement P1206R7, Conversions from ranges to containers
[Bug c++/114992] [13/14/15 Regression] ICE during IPA pass: targetclone in add_to_same_comdat_group with calling a target clone with a lamdba in a comdat function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114992 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed for 13.4/14.3/15.
[Bug target/119413] New: [15 Regression] 11% slowdown (but only 3% regression against GGC 14) of 507.cactuBSSN_r on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119413 Bug ID: 119413 Summary: [15 Regression] 11% slowdown (but only 3% regression against GGC 14) of 507.cactuBSSN_r on Aarch64 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization, needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: aarch64-gnu-linux Target: aarch64-gnu-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=585.437.0 there was a 11% exec time slowdown of the 507.cactuBSSN_r SPEC 2017 benchmark between commits r15-7776-gff38712bcba97f r15-7897-ge6e7b477bbdbfb when run with -Ofast -march=generic on an Ampere Altra Neoverse N1 machine. This is a regression against GCC 14, but only a 3% one. See the comparison here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1074.437.0&plot.9=585.437.0&; Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug fortran/119380] [12,13,14,15] Free of procedure pointer components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380 --- Comment #7 from Damian Rouson --- Thanks, Andre!
[Bug target/119408] LoongArch: Q Suffix for __float128 Literals Not Supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408 Xi Ruoyao changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-03-21 Status|UNCONFIRMED |NEW --- Comment #4 from Xi Ruoyao --- (In reply to Richard Biener from comment #1) > Q is an extension, 1.1f128 should work. The extension is enabled only > for some platforms. The reason is we already added __float128 for "compatibility with existing code" so it makes sense to add Q as well. And we have "use a suffix ‘q’ or ‘Q’ for ‘__float128’" in https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html, to me it implies if __float128 is supported, q and Q should be supported too.
[Bug target/119411] [15 Regression] 5% slowdown of 505.mcf_r on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119411 Filip Kastl changed: What|Removed |Added Target Milestone|--- |15.0
[Bug target/91614] [12/13/14 regression][arm] gcc.target/arm/unaligned-memcpy-2.c FAIL since r274986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614 Richard Earnshaw changed: What|Removed |Added Summary|[12/13/14/15|[12/13/14 regression][arm] |regression][arm]|gcc.target/arm/unaligned-me |gcc.target/arm/unaligned-me |mcpy-2.c FAIL since r274986 |mcpy-2.c FAIL since r274986 | --- Comment #13 from Richard Earnshaw --- Fixed for gcc-15
[Bug tree-optimization/119407] Missed optimization for identical branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119407
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-03-21
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
[local count: 548896824]:
*_4(D) = {};
goto ; [100.00%]
[local count: 524845000]:
MEM [(int * *)_4(D)] = { 0, 0 };
MEM[(struct _Vector_impl_data *)_4(D)]._M_end_of_storage = 0B;
[Bug sanitizer/119416] spurious store with null sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119416 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #2 from Jonathan Wakely --- There are no "official contributors", anyone who submits patches is a contributor: https://gcc.gnu.org/contribute.html
[Bug c++/114992] [13/14/15 Regression] ICE during IPA pass: targetclone in add_to_same_comdat_group with calling a target clone with a lamdba in a comdat function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114992 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:41db4716a5603052df626a1ab911b0b3fab322b2 commit r13-9442-g41db4716a5603052df626a1ab911b0b3fab322b2 Author: Jason Merrill Date: Thu Mar 20 12:57:15 2025 -0400 ipa: target clone and mangling alias [PR114992] Since the mangling of the second lambda changed (previously we counted all lambdas, now we only count lambdas with the same signature), we generate_mangling_alias for handler for backward compatibility. Since handler is COMDAT, resolve_alias puts the alias in the same comdat group as handler itself. Then create_dispatcher_calls tries to add the alias to the same comdat group as the dispatcher, but it's already in a same_comdat_group, so we ICE. It seems like we're just missing a remove_from_same_comdat_group before add_to_same_comdat_group. PR c++/114992 gcc/ChangeLog: * multiple_target.cc (create_dispatcher_calls): remove_from_same_comdat_group before add_to_same_comdat_group. gcc/testsuite/ChangeLog: * g++.target/i386/mangling-alias1.C: New test. (cherry picked from commit ab716829da7c885b97ac2649c7c0ff5c7703ffa5)
[Bug target/119421] New: [avr] Better optimize some operations involving bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119421
Bug ID: 119421
Summary: [avr] Better optimize some operations involving bits
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
There are occasions where knowledge about nonzero bits makes some
optimizations possible. For example,
Rd |= Rn << Off
can be implemented as
SBRC Rn, 0
ORI Rd, 1 << Off
when Rn in { 0, 1 }, i.e. nonzero_bits (Rn) == 1.
[Bug tree-optimization/119420] `a >> 1 == 0` should be trasformed into `((unsigned)a) <= 1`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119420 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102879 --- Comment #1 from Andrew Pinski --- Noticed while looking into PR 102879.
[Bug target/119421] [avr] Better optimize some operations involving bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119421 Georg-Johann Lay changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization Target||avr Priority|P3 |P4
[Bug tree-optimization/119420] New: `a >> 1 == 0` should be trasformed into `((unsigned)a) <= 1`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119420
Bug ID: 119420
Summary: `a >> 1 == 0` should be trasformed into `((unsigned)a)
<= 1`
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int ll(signed a)
{
int d = a >>1;
return d == 0;
}
int ll1(signed a)
{
int d = a & ~1;
return d == 0;
}
int ll2(signed a)
{
unsigned aa = a;
return aa <= 1;
}
```
All of these are the same and should be optimized to the same.
[Bug c++/114292] [12 Regression] ICE with a generic (templated) lambda capturing a constant for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292 Simon Martin changed: What|Removed |Added Summary|[12/13 Regression] ICE with |[12 Regression] ICE with a |a generic (templated) |generic (templated) lambda |lambda capturing a constant |capturing a constant for |for VLA allocation |VLA allocation Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Simon Martin --- Fixed in all active branches except 12 thats about to become unactive.
[Bug tree-optimization/119417] [14/15 Regression] wrong code with `-O2`, uses uxtw instead of uxth causing different result on ADD instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119417 --- Comment #3 from Andrew Pinski --- Created attachment 60846 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60846&action=edit Self contained testcase
[Bug target/119411] New: [15 Regression] 5% slowdown of 505.mcf_r on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119411 Bug ID: 119411 Summary: [15 Regression] 5% slowdown of 505.mcf_r on Aarch64 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization, needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: aarch64-gnu-linux Target: aarch64-gnu-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1072.347.0&plot.9=584.347.0&; there was a 5% exec time slowdown of the 505.mcf_r SPEC 2017 benchmark between commits r15-7897-ge6e7b477bbdbfb r15-8041-g57dbbdd8e34b80 when run with -Ofast -march=native on an Ampere Altra Neoverse N1 machine. This is a regression against . See the comparison here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1072.347.0&plot.9=584.347.0&; Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/119411] [15 Regression] 5% slowdown of 505.mcf_r on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119411 --- Comment #1 from Filip Kastl --- > here there should have been "GCC 14" inserted into my bugreporting template :D
[Bug target/119408] LoongArch: Q Suffix for __float128 Literals Not Supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408 --- Comment #6 from Jonathan Wakely --- (In reply to Xi Ruoyao from comment #4) > The reason is we already added __float128 for "compatibility with existing > code" so it makes sense to add Q as well. And we have "use a suffix ‘q’ or > ‘Q’ for > ‘__float128’" in https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html, to > me it implies if __float128 is supported, q and Q should be supported too. Yes, that was how I read the docs too. If the type __float128 is supported, then the Q suffix should be supported, *or* the docs should be updated to say Q isn't always supported :-)
[Bug ada/118939] [14 Regression] ada: executable segfaults on arm-linux-gnueabi when assigning an access to controlled type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939 Matthias Klose changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #5 from Matthias Klose --- from https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=armel&ver=14.2.0-19&stamp=1742057800&raw=0 Configured with: -v --with-pkgversion='Debian 14.2.0-19' --with-bugurl='file:///usr/share/doc/gcc-14/README.Bugs' --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-14 --program-prefix=arm-linux-gnueabi- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv5te --with-float=soft --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi "unusual" options might be: --with-arch=armv5te --enable-default-pie yes, there's the Debian patchset, but I'm usually not applying any code-modifying patches on my own.
[Bug target/119412] New: 7% slowdown of 482.sphinx3 on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119412 Bug ID: 119412 Summary: 7% slowdown of 482.sphinx3 on Aarch64 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization, needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: aarch64-gnu-linux Target: aarch64-gnu-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=580.280.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=579.280.0 there was a 7% exec time slowdown of the 482.sphinx3 SPEC 2006 benchmark between commits r15-7897-ge6e7b477bbdbfb r15-8041-g57dbbdd8e34b80 when run with -O2 -march=native, with and without -flto on an Ampere Altra Neoverse N1 machine. This is *not* a regression against GCC 14. See the comparison here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1042.280.0&plot.9=580.280.0&; https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1052.280.0&plot.9=579.280.0&; Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug c++/114992] [13/14/15 Regression] ICE during IPA pass: targetclone in add_to_same_comdat_group with calling a target clone with a lamdba in a comdat function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114992 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ab716829da7c885b97ac2649c7c0ff5c7703ffa5 commit r15-8651-gab716829da7c885b97ac2649c7c0ff5c7703ffa5 Author: Jason Merrill Date: Thu Mar 20 12:57:15 2025 -0400 ipa: target clone and mangling alias [PR114992] Since the mangling of the second lambda changed (previously we counted all lambdas, now we only count lambdas with the same signature), we generate_mangling_alias for handler for backward compatibility. Since handler is COMDAT, resolve_alias puts the alias in the same comdat group as handler itself. Then create_dispatcher_calls tries to add the alias to the same comdat group as the dispatcher, but it's already in a same_comdat_group, so we ICE. It seems like we're just missing a remove_from_same_comdat_group before add_to_same_comdat_group. PR c++/114992 gcc/ChangeLog: * multiple_target.cc (create_dispatcher_calls): remove_from_same_comdat_group before add_to_same_comdat_group. gcc/testsuite/ChangeLog: * g++.target/i386/mangling-alias1.C: New test.
[Bug fortran/119406] Typo in Index variable %qs at %L cannot be specified in alocality-spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119406 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- I will fix this one as well very shortly.
[Bug fortran/119403] Typo in Interface mismatch in dummy procedure at %L conflichts with %L: %s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119403 --- Comment #2 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:00cbf03029267b3bdfb696aa09c9a36dbeeb51aa commit r15-8652-g00cbf03029267b3bdfb696aa09c9a36dbeeb51aa Author: Jerry DeLisle Date: Fri Mar 21 10:13:37 2025 -0700 Fortran: Fix typo in error message. PR fortran/119403 gcc/fortran/ChangeLog: * interface.cc (compare_parameter): Fix typo.
[Bug fortran/119403] Typo in Interface mismatch in dummy procedure at %L conflichts with %L: %s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119403 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jerry DeLisle --- Simple fix.
[Bug tree-optimization/119422] New: `u <= (u <= (unsigned)b)` can be transform into just `(u <= (unsigned)b)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119422
Bug ID: 119422
Summary: `u <= (u <= (unsigned)b)` can be transform into just
`(u <= (unsigned)b)`
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
int gg(unsigned u, bool b)
{
return u <= (u <= (unsigned)b);
}
int gg1(unsigned u, bool b)
{
if (u <= (unsigned)b)
return u <= 1;
return u <= 0;
}
int gg2(unsigned u, bool b)
{
return u <= (unsigned)b;
}
```
gg should produce the same as gg1 and gg2. gg1 shows how it is true.
[Bug preprocessor/119391] [C++20] Preprocessor tokens should evaluate signed integer expressions in two's complement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391 --- Comment #10 from Jakub Jelinek --- And for GCC 16, perhaps we can keep existing behavior and just set overflow flag on the result whenever it is pedantically invalid. So for the cases like negative shift count or left shift of signed negative number.
[Bug tree-optimization/119417] [14/15 Regression] -fexpensive-optimizations forces GCC 14 to use uxtw instead of uxth causing different result on ADD instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119417 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Component|target |tree-optimization Last reconfirmed||2025-03-21 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- buggy_9 = WIDEN_MULT_PLUS_EXPR ; vs _2 = global.1_1 & 65535; _3 = _2 * 2; _4 = (long unsigned int) _3; buggy_9 = _4 + buggy_6;
[Bug libstdc++/119415] flat_set::insert_range may not handle C++20 common-range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415 --- Comment #1 from Sam James --- (In reply to 康桓瑋 from comment #0) > As an aside, seems like Tomasz recently became an "official" > contributor/maintainer of libstdc++ based on his numerous valuable libstdc++ > submission. I am just purely curious about how to become an "official" > contributor of libstdc++? Is joining Red Hat one of the qualifications? He is not listed as a maintainer. But I think this is far more appropriate on the MLs or an email to Jonathan, not here. Let's keep the bug for the range issue please.
[Bug tree-optimization/119407] Missed optimization for identical branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119407 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Severity|normal |enhancement
[Bug target/119386] [14/15 Regression][x64] Shared libraries can no longer be compiled with profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 --- Comment #35 from Ard Biesheuvel --- (In reply to Alexander Monakov from comment #34) > We have -mcmodel=kernel already, which is incompatible with -fpic. > > Ard, where is -fpic in the kernel context coming from? Kernel's top-level > Makefile passes -fno-PIE, and arch/x86/Makefile passes -mcmodel=kernel. What > is the scenario your r14-811 patch was dealing with? These days, there is quite a lot of C code in Linux that executes before the kernel virtual mapping is even up, and this code (and everything that may be called by it) needs to be position independent. Currently, we rely on fragile hacks (RIP_REL_REF() for example) to try and ensure that this works, but it would be preferred if that code (or perhaps the entire kernel) could be built with -fPIC. There is some pushback to this, given that RIP-relative LEA is sometimes more expensive that a plain MOV (depending on the uarch) but not being able to use both -fPIC and -pg in the kernel was an impediment. (The indirect call opcode is longer, and does not honour -mnop-mcount, which is an issue for us)
[Bug fortran/119403] Typo in Interface mismatch in dummy procedure at %L conflichts with %L: %s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119403 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- I will fix it shortly.
[Bug tree-optimization/119417] New: -fexpensive-optimizations forces GCC 14 to use uxtw instead of uxth causing different result on ADD instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119417
Bug ID: 119417
Summary: -fexpensive-optimizations forces GCC 14 to use uxtw
instead of uxth causing different result on ADD
instruction
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
Greetings,
GCC 14 running on aarch64 architecture, our team detected a unique behavior
that only happens when we use the optimization “-fexpensive-optimizations”.
We noted that the line “buggy = buggy + ((global & 0x) * 2);” from the code
below has different instructions if using the “-fexpensive-optimizations” or
not.
# With -fexpensive-optimizations uses uxtw
add x19, x19, w0, uxtw 1
# Without -fexpensive-optimizations uses uxth
add x19, x19, w0, uxth 1
The reduced testcase is available at https://godbolt.org/z/vM9Y4dMnW.
To reproduce use the command "gcc -O1 -fexpensive-optimizations":
#include
__attribute__((noinline)) void print(size_t toPrint)
{
std::cout << toPrint << std::endl;
}
unsigned global = 0x1;
int main()
{
size_t buggy = 0;
while (true)
{
buggy = buggy + ((global & 0x) * 2);
print(buggy);
if (global)
break;
}
}
This source code returns 0 when NOT using “-fexpensive-optimizations” and
returns 131072 when using this flag or -O2 or higher optimization.
We tested it with older GCC versions and also LLVM, only GCC 14 on Arm returns
131072.
Knowning that UXTH extends a 16-bit unsigned value to a 32-bit register and
UXTW
extends a 32-bit unsigned value to a 64-bit register, forcing a uint16_t cast
fixes this behavior as the example below:
buggy = buggy + (static_cast(global & 0x) * 2);
print(buggy);
This GCC 14 behavior is a bug or it is expected and the other versions and LLVM
should be fixed?
Regards,
Rogerio
[Bug cobol/119390] stack buffer overflow in gcobol driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119390 Andreas Schwab changed: What|Removed |Added Summary|cobol compiler crashes with |stack buffer overflow in |buffer overflow |gcobol driver Status|UNCONFIRMED |NEW Keywords|testsuite-fail | Last reconfirmed||2025-03-21 Ever confirmed|0 |1
[Bug target/119417] [14/15 Regression] -fexpensive-optimizations forces GCC 14 to use uxtw instead of uxth causing different result on ADD instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119417 Andrew Pinski changed: What|Removed |Added Known to work||13.3.0 Summary|-fexpensive-optimizations |[14/15 Regression] |forces GCC 14 to use uxtw |-fexpensive-optimizations |instead of uxth causing |forces GCC 14 to use uxtw |different result on ADD |instead of uxth causing |instruction |different result on ADD ||instruction Target Milestone|--- |14.3 Keywords||wrong-code Known to fail||14.1.0
[Bug tree-optimization/119417] [14/15 Regression] -fexpensive-optimizations forces GCC 14 to use uxtw instead of uxth causing different result on ADD instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119417 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113560 --- Comment #2 from Andrew Pinski --- Which most likely then it is caused by r14-8680-g2f14c0dbb78985 .
