[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 --- Comment #11 from Paul Thomas --- (In reply to anlauf from comment #10) > (In reply to Paul Thomas from comment #9) > > (In reply to anlauf from comment #8) > > > I get the same behavior at r13-8559 as 14-mainline. There seems to be > > > another commit that fixed it independently. > > > > > > Removing 13-branch from the regression list. > > > > Mark as fixed or backport fixes? > > Either I did something wrong, or the bug reappeared on 13-branch... > > Anyway, I tried backporting Andre's patch to 13- and 12-branch. > Works fine and regtests fine. > > How to proceed? > > I can push those changes, so that we are finally done with this PR. Hi Harald, It would be splendid if you would backport the patch. In the last week or so, I have built up quite a list of backports to do, which I will attend to over the weekend. We are down from 105 regressions on 26th March to 94 now, of which 13 are now fixed on mainline. Since there are still some P1 regressions, I have been prowling around looking for more low hanging edibles while there is still time. Regards Paul
[Bug fortran/114859] New: Seeing new segmentation fault in same_type_as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
Bug ID: 114859
Summary: Seeing new segmentation fault in same_type_as
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: orion at nwra dot com
Target Milestone: ---
As seen here:
https://koschei.fedoraproject.org/package/amg4psblas?collection=f40 with the
change from 14.0.1-0.13.fc40 to
14.0.1-0.15.fc40 we are starting to see a new segmentation fault in a test
program.
gdb shows:
Thread 1 "amg_d_pde2d" received signal SIGSEGV, Segmentation fault.
0x77aee1b0 in amg_d_jac_smoother_clone_settings_ (sm=..., smout=...,
info=0) at ../amgprec/impl/smoother/amg_d_jac_smoother_clone_settings.f90:66
66if (.not.same_type_as(sm%sv,smout%sv)) then
(gdb) print sm
$1 = {_data = 0x55733100, _vptr = 0x77dbf360
<__amg_d_jac_smoother_MOD___vtab_amg_d_jac_smoother_Amg_d_jac_smoother_type>}
(gdb) print smout
$2 = {_data = 0x5572bc00, _vptr = 0x77dbf360
<__amg_d_jac_smoother_MOD___vtab_amg_d_jac_smoother_Amg_d_jac_smoother_type>}
valgrind:
==73== Conditional jump or move depends on uninitialised value(s)
==73==at 0x49961A1: amg_d_jac_smoother_clone_settings_ (in
/builddir/build/BUILDROOT/amg4psblas-1.1.2-5.fc41.x86_64/usr/lib64/openmpi/lib/libamg_prec.so.1.1)
==73==by 0x4C0E736: ??? (in
/builddir/build/BUILDROOT/amg4psblas-1.1.2-5.fc41.x86_64/usr/lib64/openmpi/lib/libamg_prec.so.1.1)
==73==by 0x4A7825B: amg_d_hierarchy_bld_ (in
/builddir/build/BUILDROOT/amg4psblas-1.1.2-5.fc41.x86_64/usr/lib64/openmpi/lib/libamg_prec.so.1.1)
==73==by 0x10F770: MAIN__ (amg_d_pde2d.F90:409)
==73==by 0x10BBD2: main (amg_d_pde2d.F90:67)
==73==
==73== Uninitialised byte(s) found during client check request
==73==at 0x7B61B51: ??? (in /usr/lib64/openmpi/lib/libopen-pal.so.80.0.2)
==73==by 0x69F2ED6: PMPI_Bcast (in
/usr/lib64/openmpi/lib/libmpi.so.40.40.2)
==73==by 0x5FDE07B: MPI_BCAST (in
/usr/lib64/openmpi/lib/libmpi_mpifh.so.40.40.0)
==73==by 0x4F20D69: __psi_m_collective_mod_MOD_psb_mbcasts (in
/usr/lib64/openmpi/lib/libpsb_base.so.3.8)
==73==by 0x4AC9B1E: __amg_base_prec_type_MOD_amg_dml_bcast (in
/builddir/build/BUILDROOT/amg4psblas-1.1.2-5.fc41.x86_64/usr/lib64/openmpi/lib/libamg_prec.so.1.1)
==73==by 0x4A800B5: amg_d_hierarchy_bld_ (in
/builddir/build/BUILDROOT/amg4psblas-1.1.2-5.fc41.x86_64/usr/lib64/openmpi/lib/libamg_prec.so.1.1)
==73==by 0x10F770: MAIN__ (amg_d_pde2d.F90:409)
==73==by 0x10BBD2: main (amg_d_pde2d.F90:67)
==73== Address 0x3e6a471c is 5,612 bytes inside a block of size 109,760
alloc'd
==73==at 0x484382F: malloc (vg_replace_malloc.c:446)
==73==by 0x4A32781: amg_dprecinit_ (in
/builddir/build/BUILDROOT/amg4psblas-1.1.2-5.fc41.x86_64/usr/lib64/openmpi/lib/libamg_prec.so.1.1)
==73==by 0x10F52B: MAIN__ (amg_d_pde2d.F90:279)
==73==by 0x10BBD2: main (amg_d_pde2d.F90:67)
==73==
The only warning I see for that function's source file is:
amg_d_jac_smoother_clone_settings.f90:48:28:
48 | character(len=20) :: name='d_jac_smoother_clone_settings'
|1
Warning: CHARACTER expression at (1) is being truncated (29/20)
[-Wcharacter-truncation]
which seems unrelated.
I'm at a loss with how to proceed to debug this further.
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 --- Comment #11 from Jerry DeLisle --- I am able to run your reproducer and I can see the increasing times as the number of modules goes up. I am curious if you could randomize the subroutine names? These appear fairly repetitive and I wonder if this biases the test. My results: Build time for base.F90 in Modules_100: 0.446443 seconds Number of Modules | Build Time - | -- 10 | 0.0155371 20 | 0.024554 30 | 0.041164 40 | 0.0620602 50 | 0.092014 60 | 0.135193 70 | 0.184979 80 | 0.255272 90 | 0.335244 100 | 0.446443 real0m27.194s user2m27.698s sys 0m21.231s The build time presented appears to not be wall time so I wonder what this is.
[Bug c++/114856] [14 regression][modules] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114856
Nathaniel Shead changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||nshead at gcc dot gnu.org
Last reconfirmed||2024-04-26
Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot
gnu.org
--- Comment #1 from Nathaniel Shead ---
Minimised:
module;
namespace std {
template struct initializer_list {
int *_M_array;
unsigned long _M_len;
};
struct basic_string {
~basic_string();
};
}
export module repro;
struct A {
std::basic_string data3;
};
struct V {
V(std::initializer_list);
};
struct data {
V v{{}};
};
[Bug c++/114858] [11/12/13/14 regression] Compilation Hang and Excessive RAM Consumption in GCC with invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Summary|[11/12/13/14 regression]|[11/12/13/14 regression] |Compilation Hang and|Compilation Hang and |Excessive RAM Consumption |Excessive RAM Consumption |in GCC |in GCC with invalid input Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-26 --- Comment #1 from Andrew Pinski --- Confirmed. Looks like a patch which was backported to the GCC 4.8.4 release is the cause.
[Bug c++/114858] [11/12/13/14 regression] Compilation Hang and Excessive RAM Consumption in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858 Andrew Pinski changed: What|Removed |Added Known to fail||4.8.4, 4.8.5 Known to work||4.8.2, 4.8.3 Target Milestone|--- |11.5 Summary|Compilation Hang and|[11/12/13/14 regression] |Excessive RAM Consumption |Compilation Hang and |in GCC |Excessive RAM Consumption ||in GCC
[Bug c++/114858] New: Compilation Hang and Excessive RAM Consumption in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858
Bug ID: 114858
Summary: Compilation Hang and Excessive RAM Consumption in GCC
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
The following code snippet triggers a hang issue:
$ cat bug.cpp
template void g(F);
template
auto h(A &&... a) -> decltype(g(0,
(g)(a)...))
{
h([] {});
}
int main() {
h();
return 0;
}
I observed that when attempting to compile this code using GCC, the compilation
process hangs indefinitely, without providing any output or indicating
successful compilation. Additionally, the RAM usage continuously increases,
leading to excessive consumption of system resources.
However, it is worth noting that when using LLVM as the compiler, the code
compiles quickly and produces the expected compilation output.
We have found that this issue still persists in the latest version of GCC(see
https://godbolt.org/z/P1c7f664f)
The command we used is(no error output):
g++ bug.cpp
The GCC version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/cTest/gcc/myinstall/libexec/gcc/x86_64-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure -v --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --enable-checking=no
--enable-languages=c,c++ --disable-multilib --prefix=/home/cTest/gcc/myinstall
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240329 (experimental) (GCC)
[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #15 from Andrew Pinski --- Created attachment 58043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58043=edit Patch but no testcases yet Will add testcases in a little bit. Also I have not tested this fully yet. Will do tonight.
[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/gnustep/ ||libobjc2/issues/247 --- Comment #14 from Andrew Pinski --- I tested alloca and large stack sizes, they both look good to me. I will add runtime testcase for both. not omitting FP also looks correct. The patch itself is most contained in aarch64_pop_regs/aarch64_restore_callee_saves which just skips the restore if the regno was eh_return_data_regno and returning normally. > no tests tried to return a value on the non-exception path well libobjc2 does and that is how this was originally root caused even: https://github.com/gnustep/libobjc2/issues/247
[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #13 from Wilco --- (In reply to Andrew Pinski from comment #11) > I have a fix for aarch64, able to produce now: > ``` > f: > .LFB0: > .cfi_startproc > stp x0, x1, [sp, -32]! > .cfi_def_cfa_offset 32 > .cfi_offset 0, -32 > .cfi_offset 1, -24 > stp x2, x3, [sp, 16] > .cfi_offset 2, -16 > .cfi_offset 3, -8 > ldr w0, [x0] > cmp w0, 5 > bne .L8 > add sp, sp, 32 > .cfi_remember_state > .cfi_def_cfa_offset 0 > ret > .L8: > .cfi_restore_state > mov x5, x1 > ldp x2, x3, [sp, 16] > ldp x0, x1, [sp], 32 > .cfi_restore 1 > .cfi_restore 0 > .cfi_restore 2 > .cfi_restore 3 > .cfi_def_cfa_offset 0 > add sp, sp, x5 > ret > .cfi_endproc > ``` > > Which is exactly what we should produce I think. > The patch is a bit more complex than I expected but that is due to how > aarch64 has some of the most complex epilogues. I'm not convinced that is an easy solution. Try various cases with large stack sizes, alloca and other scalar and FP callee-saves. Getting all cases right and writing good tests for them is a lot of work.
[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #12 from Andrew Pinski --- (In reply to Wilco from comment #10) > Since the whole eh_return is an internal ABI in libgcc, a fix would be to > change EH_RETURN_DATA_REGNO(N) to avoid x0 and x1. Since eh_return already > reserves 7 registers(!) and now need to avoid using x0/x1 too, using x2-x5 > and x6,x7 and x9 for the other special registers should work. You can't change EH_RETURN_DATA_REGNO now because it is not just internal ABI to libgcc, it is part of libstdc++v3 too (libsupc++/eh_personality.cc): /* For targets with pointers smaller than the word size, we must extend the pointer, and this extension is target dependent. */ _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), __builtin_extend_pointer (ue_header)); _Unwind_SetGR (context, __builtin_eh_return_data_regno (1), handler_switch_value); And libobjc: exception.c:#define __builtin_eh_return_data_regno(x) x exception.c: _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), exception.c: _Unwind_SetGR (context, __builtin_eh_return_data_regno (1), And really any exception personality.
[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #11 from Andrew Pinski --- I have a fix for aarch64, able to produce now: ``` f: .LFB0: .cfi_startproc stp x0, x1, [sp, -32]! .cfi_def_cfa_offset 32 .cfi_offset 0, -32 .cfi_offset 1, -24 stp x2, x3, [sp, 16] .cfi_offset 2, -16 .cfi_offset 3, -8 ldr w0, [x0] cmp w0, 5 bne .L8 add sp, sp, 32 .cfi_remember_state .cfi_def_cfa_offset 0 ret .L8: .cfi_restore_state mov x5, x1 ldp x2, x3, [sp, 16] ldp x0, x1, [sp], 32 .cfi_restore 1 .cfi_restore 0 .cfi_restore 2 .cfi_restore 3 .cfi_def_cfa_offset 0 add sp, sp, x5 ret .cfi_endproc ``` Which is exactly what we should produce I think. The patch is a bit more complex than I expected but that is due to how aarch64 has some of the most complex epilogues.
[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #10 from Wilco --- (In reply to Andrew Pinski from comment #9) > Just a quick note here. Even though eh_return pattern was removed with > r7-6051-g8144a493ddc008, it was broken before that patch. Yeah I only fixed the broken behaviours that I encountered at the time - no tests tried to return a value on the non-exception path. There is no clear specification (eg. making it clear that EH_RETURN_DATA_REGNO must not overlap with registers used to return or if they do, you need to conditionally restore them), so no wonder that many targets get this wrong. Who knew that introducing lots of complex builtins that affect prolog and epilog generation in a major way to avoid a few lines of assembly code was such a bad idea... Since the whole eh_return is an internal ABI in libgcc, a fix would be to change EH_RETURN_DATA_REGNO(N) to avoid x0 and x1. Since eh_return already reserves 7 registers(!) and now need to avoid using x0/x1 too, using x2-x5 and x6,x7 and x9 for the other special registers should work.
[Bug c++/114857] New: Pointer attributes and qualifiers are parsed in wrong order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114857 Bug ID: 114857 Summary: Pointer attributes and qualifiers are parsed in wrong order Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: luigighiron at gmail dot com Target Milestone: --- GCC accepts the following declaration: int*const[[]]p=0; And rejects the following declaration: int*[[]]const p=0; It seems that GCC expects the attributes of a pointer declarator to come after the qualifiers. The standard specifies in the grammar that the attributes should come before qualifiers and not after: > ptr-operator: > * attribute-specifier-seq opt cv-qualifier-seq opt > & attribute-specifier-seq opt > && attribute-specifier-seq opt > nested-name-specifier * attribute-specifier-seq opt cv-qualifier-seq opt Section 9.3.1 "General" [dcl.decl.general] Paragraph 5 ISO/IEC 14882:2020 The first declaration should be rejected and the second declaration should be accepted. Clang and MSVC get this correct (though not EDG I think so Visual Studio will show errors in the correct declarations and not in the incorrect declarations), and GCC gets this correct with pointer to members but not with normal pointers.
[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846 --- Comment #3 from Andrew Pinski --- (In reply to Kewen Lin from comment #2) > As https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843#c8, we may need some > similar handling like r14-6440-g4b421728289e6f. Note rs6000_emit_epilogue mostly handles eh_returns so it might not be as hard as other targets.
[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77455 --- Comment #9 from Andrew Pinski --- Just a quick note here. Even though eh_return pattern was removed with r7-6051-g8144a493ddc008, it was broken before that patch.
[Bug c++/114856] New: [14 regression][modules] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114856
Bug ID: 114856
Summary: [14 regression][modules] ICE (segfault)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: D.Klein at gsi dot de
Target Milestone: ---
Created attachment 58042
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58042=edit
/tmp/ccHpxCro.out - preprocessed source
❯ cat repro.cpp
module;
#include
#include
#include
export module repro;
export struct data {
std::vector> asdf{{"42","42","42"}};
};
❯ g++ -v -save-temps -freport-bug -fmodules-ts repro.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/dklein/gcc-master/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/dklein/gcc-master
--disable-multilib --disable-bootstrap : (reconfigured) ./configure
--prefix=/home/dklein/gcc-master --disable-multilib --disable-bootstrap :
(reconfigured) ./configure --prefix=/home/dklein/gcc-master --disable-multilib
--disable-bootstrap --enable-languages=c,c++,fortran,lto,objc --no-create
--no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240425 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-fmodules-ts'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/home/dklein/gcc-master/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/cc1plus -E
-quiet -v -D_GNU_SOURCE repro.cpp -mtune=generic -march=x86-64 -freport-bug
-fmodules-ts -fpch-preprocess -o a-repro.ii
ignoring nonexistent directory
"/home/dklein/gcc-master/lib/gcc/x86_64-pc-linux-gnu/14.0.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/dklein/gcc-master/lib/gcc/x86_64-pc-linux-gnu/14.0.1/../../../../include/c++/14.0.1
/home/dklein/gcc-master/lib/gcc/x86_64-pc-linux-gnu/14.0.1/../../../../include/c++/14.0.1/x86_64-pc-linux-gnu
/home/dklein/gcc-master/lib/gcc/x86_64-pc-linux-gnu/14.0.1/../../../../include/c++/14.0.1/backward
/home/dklein/gcc-master/lib/gcc/x86_64-pc-linux-gnu/14.0.1/include
/usr/local/include
/home/dklein/gcc-master/include
/home/dklein/gcc-master/lib/gcc/x86_64-pc-linux-gnu/14.0.1/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-fmodules-ts'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/home/dklein/gcc-master/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/cc1plus
-fpreprocessed a-repro.ii -quiet -dumpdir a- -dumpbase repro.cpp -dumpbase-ext
.cpp -mtune=generic -march=x86-64 -version -freport-bug -fmodules-ts -o
a-repro.s
GNU C++17 (GCC) version 14.0.1 20240425 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 14.0.1 20240411 (Red Hat 14.0.1-0), GMP
version 6.2.1, MPFR version 4.2.1, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 66103b0a3eb595c28eae89ea7eb332ba
repro.cpp:7:9: internal compiler error: Segmentation fault
7 | export module repro;
| ^~
0x12ff8df crash_signal
../.././gcc/toplev.cc:319
0xb512ae tree_check(tree_node*, char const*, int, char const*, tree_code)
../.././gcc/tree.h:3623
0xb512ae get_merge_kind
../.././gcc/cp/module.cc:10679
0xb512ae decl_value
../.././gcc/cp/module.cc:7787
0xb5a4a3 depset::hash::find_dependencies(module_state*)
../.././gcc/cp/module.cc:13592
0xb5b2f3 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
../.././gcc/cp/module.cc:18198
0xb5c9a4 finish_module_processing(cpp_reader*)
../.././gcc/cp/module.cc:20562
0xae6ee1 c_parse_final_cleanups()
../.././gcc/cp/decl2.cc:5357
0xd37c50 c_common_parse_file()
../.././gcc/c-family/c-opts.cc:1329
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Preprocessed source stored into /tmp/ccHpxCro.out file, please attach this to
your bugreport.
repro.cpp compiles with GCC 13.2.0 (https://godbolt.org/z/Ph834fvja). A git
bisect from 1604f7cebc49220e47d584615bcd91b1fdc1267f to releases/gcc-13.2.0
suggests the following commit to introduce the regression:
commit 2823b4d96d9ec4ad4e67e5e8edaa1b060a467491
Author: Nathaniel Shead
Date: Thu Feb 29 22:49:13 2024 +1100
c++: Ensure DECL_CONTEXT is set for temporary vars [PR114005]
Modules streaming requires DECL_CONTEXT to be set for anything streamed.
This patch ensures that 'create_temporary_var' does set a DECL_CONTEXT
for these variables (such as the backing storage for initializer_list
[Bug middle-end/114855] ICE: Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #2 from Andrew Pinski --- The code basically does a bunch of: const SWord8 s599 = s557 ? s595 : s598; const SWord8 s600 = s561 ? 14 : 246; const SWord8 s601 = s561 ? 3 : 72; const SWord8 s602 = s559 ? s600 : s601; const SWord8 s603 = s561 ? 102 : 181; const SWord8 s604 = s561 ? 62 : 112; const SWord8 s605 = s559 ? s603 : s604; const SWord8 s606 = s557 ? s602 : s605; const SWord8 s607 = s555 ? s599 : s606; const SWord8 s608 = s561 ? 138 : 139; Continuously.
[Bug middle-end/114855] ICE: Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #1 from Andrew Pinski --- Worthing noting on the trunk most of the compile time seems to be in the ranger code ...
[Bug c/114855] New: ICE: Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 Bug ID: 114855 Summary: ICE: Segfault Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jeremy.rutman at gmail dot com Target Milestone: --- Created attachment 58041 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58041=edit output from gcc -v Attempt to compile some autogenerated code resulted in `cc: internal compiler error: Segmentation fault signal terminated program cc1` . Compile command was gcc -v -Wall -O3 -DNDEBUG -fomit-frame-pointer -freport-bug -save-temps -c aesDecrypt.c -o aesDecrypt.o I put the offending source file aesDecrypt.c here: https://paste.c-net.org/ExamineLarch and the .i file from the -save-temps aesDecrypt.i here https://paste.c-net.org/TiredInduce I'm not sure what the -freport-bug is doing but I used it in the compile command anyway. Apologies for the unwieldy size of the autogenerated code being compiled.
[Bug target/111610] Cannot build cross compiler to darwin targets after r14-4108-g47346acb72b50d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610 --- Comment #7 from GCC Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:1fd4db58480a518b05dd835157e59b2ed9fd2bc1 commit r11-11371-g1fd4db58480a518b05dd835157e59b2ed9fd2bc1 Author: Iain Sandoe Date: Wed Sep 27 11:05:31 2023 +0100 Darwin, configure: Allow for an unrecognisable dsymutil [PR111610]. We had a catch-all configuration case for missing or unrecognised dsymutil but it was setting the dsymutil source to "UNKNOWN" which is not usable in this context (since it clashes with an existing enum). We rename this to DET_UNKNOWN (for Darwin External Toolchain). PR target/111610 gcc/ChangeLog: * configure: Regenerate. * configure.ac: Rename the missing dsymutil case to "DET_UNKNOWN". Signed-off-by: Iain Sandoe (cherry picked from commit 2ecab2f32b9e9a75bf563f80752d5b44dcd26b98)
[Bug lto/113208] [15 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|14.0|15.0 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[14 Regression] lto1: |[15 Regression] lto1: |error: Alias and target's |error: Alias and target's |comdat groups differs since |comdat groups differs since |r14-5979-g99d114c15523e0|r14-5979-g99d114c15523e0 --- Comment #35 from Jakub Jelinek --- Should be fixed for 14.1 now. Keeping it open to redo it in stage1 differently as discussed on the mailing list.
[Bug c++/111284] [11/12/13 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Some |Some passing-by-value |passing-by-value parameters |parameters are mishandled |are mishandled since GCC 9, |since GCC 9, affecting |affecting libstdc++'s |libstdc++'s constexpr |constexpr std::string |std::string | Status|NEW |ASSIGNED --- Comment #11 from Jakub Jelinek --- Should be fixed on the trunk (upcoming 14.1).
[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 --- Comment #10 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f541757ba4632e204169dd08a5f10c782199af42 commit r14-10134-gf541757ba4632e204169dd08a5f10c782199af42 Author: Jakub Jelinek Date: Thu Apr 25 20:45:04 2024 +0200 c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284] My r9-6136 changes to make a copy of constexpr function bodies before genericization modifies it broke the constant evaluation of non-POD arguments passed by value. In the callers such arguments are passed as reference to usually a TARGET_EXPR, but on the callee side until genericization they are just direct uses of a PARM_DECL with some class type. In cxx_bind_parameters_in_call I've used convert_from_reference to pretend it is passed by value and then cxx_eval_constant_expression is called there and evaluates that as an rvalue, followed by adjust_temp_type if the types don't match exactly (e.g. const Foo argument and passing to it reference to Foo TARGET_EXPR). The reason this doesn't work is that when the TARGET_EXPR in the caller is constant initialized, this for it is the address of the TARGET_EXPR_SLOT, but if the code later on pretends the PARM_DECL is just initialized to the rvalue of the constant evaluation of the TARGET_EXPR, it is as if there is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee is then address of the PARM_DECL in the callee. The following patch attempts to fix that by constexpr evaluation of such arguments in the caller as an lvalue instead of rvalue, and on the callee side when seeing such a PARM_DECL, if we want an lvalue, lookup the value (lvalue) saved in ctx->globals (if any), and if wanting an rvalue, recursing with vc_prvalue on the looked up value (because it is there as an lvalue, nor rvalue). adjust_temp_type doesn't work for lvalues of non-scalarish types, for such types it relies on changing the type of a CONSTRUCTOR, but on the other side we know what we pass to the argument is addressable, so the patch on type mismatch takes address of the argument value, casts to reference to the desired type and dereferences it. 2024-04-25 Jakub Jelinek PR c++/111284 * constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for cxx_eval_constant_expression and if it doesn't have the same type as it should, cast the reference type to reference to type before convert_from_reference and instead of adjust_temp_type take address of the arg, cast to reference to type and then convert_from_reference. (cxx_eval_constant_expression) : For lval case on parameters with TREE_ADDRESSABLE types lookup result in ctx->globals if possible. Otherwise if lookup in ctx->globals was successful for parameter with TREE_ADDRESSABLE type, recurse with vc_prvalue on the returned value. * g++.dg/cpp1z/constexpr-111284.C: New test. * g++.dg/cpp1y/constexpr-lifetime7.C: Expect one error on a different line.
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 Bug 87189 depends on bug 78017, which changed state. Bug 78017 Summary: weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken with new enough glibc (GTHREAD_USE_WEAK can be defined to 0 now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Andrew Pinski --- Fixed: https://gcc.gnu.org/pipermail/gcc-cvs/2024-April/401301.html
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #6 from Neil Carlson --- Here's a variation of the example involving arrays. I expect the source of the failure here is the same, but I want to be sure this example is also fixed by the eventual patch. program main call run contains subroutine run class(*), allocatable :: y(:) call foo(['fubar','fubar'], y) end subroutine subroutine foo(a, b) class(*), intent(in) :: a(:) class(*), allocatable :: b(:) b = a !allocate(b, source=a) ! VALGRIND REPORTS NO INVALID WRITES end subroutine end program Compiled with -fsanitize=address and executed gives this: ==1338704==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200072 at pc 0x7fb456a4c8d1 bp 0x7ffcfd375d50 sp 0x7ffcfd375500 WRITE of size 5 at 0x60200072 thread T0 #0 0x7fb456a4c8d0 in __interceptor_memmove ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810 #1 0x4012d4 in __copy_character_1 /home/nnc/Codes/petaca/bugs/fubar.f90:1 #2 0x401c9f in foo /home/nnc/Codes/petaca/bugs/fubar.f90:11 #3 0x4023e8 in run /home/nnc/Codes/petaca/bugs/fubar.f90:6 #4 0x40137e in MAIN__ /home/nnc/Codes/petaca/bugs/fubar.f90:2 #5 0x4027a1 in main /home/nnc/Codes/petaca/bugs/fubar.f90:2 #6 0x7fb4563ff149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) #7 0x7fb4563ff20a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) #8 0x401184 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401184) 0x60200072 is located 0 bytes to the right of 2-byte region [0x60200070,0x60200072) allocated by thread T0 here: #0 0x7fb456abd69f in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x401965 in foo /home/nnc/Codes/petaca/bugs/fubar.f90:11 #2 0x4023e8 in run /home/nnc/Codes/petaca/bugs/fubar.f90:6 #3 0x40137e in MAIN__ /home/nnc/Codes/petaca/bugs/fubar.f90:2 #4 0x4027a1 in main /home/nnc/Codes/petaca/bugs/fubar.f90:2 #5 0x7fb4563ff149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) #6 0x7fb4563ff20a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) #7 0x401184 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401184) SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:810 in __interceptor_memmove
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #34 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c39654e7a431992773b48d61f804494b0d70855f
commit r14-10132-gc39654e7a431992773b48d61f804494b0d70855f
Author: Jakub Jelinek
Date: Thu Apr 25 20:37:10 2024 +0200
c++: Retry the aliasing of base/complete cdtor optimization at
import_export_decl time [PR113208]
When expand_or_defer_fn is called at_eof time, it calls import_export_decl
and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
couple of places to try to optimize cdtors which are known to have the
same body by making the complete cdtor an alias to base cdtor (and in
that case also uses *[CD]5* as comdat group name instead of the normal
comdat group names specific to each mangled name).
Now, this optimization depends on DECL_ONE_ONLY and DECL_INTERFACE_KNOWN,
maybe_clone_body and can_alias_cdtor use:
if (DECL_ONE_ONLY (fn))
cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group
(clone));
...
bool can_alias = can_alias_cdtor (fn);
...
/* Tell cgraph if both ctors or both dtors are known to have
the same body. */
if (can_alias
&& fns[0]
&& idx == 1
&& cgraph_node::get_create (fns[0])->create_same_body_alias
(clone, fns[0]))
{
alias = true;
if (DECL_ONE_ONLY (fns[0]))
{
/* For comdat base and complete cdtors put them
into the same, *[CD]5* comdat group instead of
*[CD][12]*. */
comdat_group = cdtor_comdat_group (fns[1], fns[0]);
cgraph_node::get_create (fns[0])->set_comdat_group
(comdat_group);
if (symtab_node::get (clone)->same_comdat_group)
symtab_node::get (clone)->remove_from_same_comdat_group ();
symtab_node::get (clone)->add_to_same_comdat_group
(symtab_node::get (fns[0]));
}
}
and
/* Don't use aliases for weak/linkonce definitions unless we can put both
symbols in the same COMDAT group. */
return (DECL_INTERFACE_KNOWN (fn)
&& (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
&& (!DECL_ONE_ONLY (fn)
|| (HAVE_COMDAT_GROUP && DECL_WEAK (fn;
The following testcase regressed with Marek's r14-5979 change,
when pr113208_0.C is compiled where the ctor is marked constexpr,
we no longer perform this optimization, where
_ZN6vectorI12QualityValueEC2ERKS1_ was emitted in the
_ZN6vectorI12QualityValueEC5ERKS1_ comdat group and
_ZN6vectorI12QualityValueEC1ERKS1_ was made an alias to it,
instead we emit _ZN6vectorI12QualityValueEC2ERKS1_ in
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group and the same
content _ZN6vectorI12QualityValueEC1ERKS1_ as separate symbol in
_ZN6vectorI12QualityValueEC1ERKS1_ comdat group.
Now, the linker seems to somehow cope with that, eventhough it
probably keeps both copies of the ctor, but seems LTO can't cope
with that and Honza doesn't know what it should do in that case
(linker decides that the prevailing symbol is
_ZN6vectorI12QualityValueEC2ERKS1_ (from the
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group) and
_ZN6vectorI12QualityValueEC1ERKS1_ alias (from the other TU,
from _ZN6vectorI12QualityValueEC5ERKS1_ comdat group)).
Note, the case where some constructor is marked constexpr in one
TU and not in another one happens pretty often in libstdc++ when
one mixes -std= flags used to compile different compilation units.
The reason the optimization doesn't trigger when the constructor is
constexpr is that expand_or_defer_fn is called in that case much earlier
than when it is not constexpr; in the former case it is called when we
try to constant evaluate that constructor. But DECL_INTERFACE_KNOWN
is false in that case and comdat_linkage hasn't been called either
(I think it is desirable, because comdat group is stored in the cgraph
node and am not sure it is a good idea to create cgraph nodes for
something that might not be needed later on at all), so maybe_clone_body
clones the bodies, but doesn't make them as aliases.
The following patch is an attempt to redo this optimization when
import_export_decl is called at_eof time on the base/complete cdtor
(or deleting dtor). It will not do anything if maybe_clone_body
hasn't been called uyet (the TREE_ASM_WRITTEN check on the
DECL_MAYBE_IN_CHARGE_CDTOR_P), or when one or both of the base/complete
cdtors have been lowered already, or when maybe_clone_body called
maybe_thunk_body and it was successful. Otherwise retries the
can_alias_cdtor check and makes
[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #9) > (In reply to anlauf from comment #8) > > I get the same behavior at r13-8559 as 14-mainline. There seems to be > > another commit that fixed it independently. > > > > Removing 13-branch from the regression list. > > Mark as fixed or backport fixes? Either I did something wrong, or the bug reappeared on 13-branch... Anyway, I tried backporting Andre's patch to 13- and 12-branch. Works fine and regtests fine. How to proceed? I can push those changes, so that we are finally done with this PR.
[Bug fortran/114825] [11/12/13 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |Compiler error using|Compiler error using |gfortran and OpenMP since |gfortran and OpenMP since |r5-1190 |r5-1190 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 --- Comment #5 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:14d48516e588ad2b35e2007b3970bdcb1b3f145c commit r14-10130-g14d48516e588ad2b35e2007b3970bdcb1b3f145c Author: Jakub Jelinek Date: Thu Apr 25 20:09:35 2024 +0200 openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl copy [PR114825] tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used both for debug info and OpenMP/OpenACC lowering purposes, the other solely for OpenMP/OpenACC lowering purposes. When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks (mostly Fortran, C just a little and C++ doesn't have nested functions) then inspect the flags on the vars and based on that decide how to lower the corresponding clauses. Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?, so the langhooks made decisions on the default flags on those instead. As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL, using copy_node wouldn't work properly, so this patch just copies those flags in addition to other flags it was copying already. And I've removed code duplication by introducing a helper function which does copying common to both uses. 2024-04-25 Jakub Jelinek PR fortran/114825 * tree-nested.cc (get_debug_decl): New function. (get_nonlocal_debug_decl): Use it. (get_local_debug_decl): Likewise. * gfortran.dg/gomp/pr114825.f90: New test.
[Bug middle-end/114853] Inefficient code with a bunch of bitwise checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #4 from Andrew Pinski ---
So what is happening is there is a missed Canonicalization happening here at
the gimple level and only at the RTL level we decide to expand `(num & 7LL) ==
7LL` as `((~num) & 7) == 0` (for x86_64). For aarch64 we expand still as `(num
&7) == 7`.
So we should pick one for the gimple level and then expand it and also actually
do better CSE of `~num` for the RTL level.
The other thing GCC should do better at is handle:
```
bool checko(long long num) {
if((num & 7LL) == 7LL)
return true;
if((num & 22LL) == 22LL)
return true;
return false;
}
```
Into:
```
and x1, x0, 7
mov x2, 22
cmp x1, 7
and x0, x0, x2
ccmpx0, x2, 4, ne
csetw0, eq
```
For aarch64.
I have an idea there ...
[Bug modula2/114836] error messages should be translatable and follow locale convention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114836 --- Comment #1 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:d0e1e1291b10372d71ad3d6cb66b333ea91097e7 commit r14-10124-gd0e1e1291b10372d71ad3d6cb66b333ea91097e7 Author: Gaius Mulley Date: Thu Apr 25 18:31:55 2024 +0100 PR modula2/114836 Avoid concatenation of error strings to aid error locale translation This patch avoids a concatenation of error strings making locale translation of the error message easier. gcc/m2/ChangeLog: PR modula2/114836 * gm2-compiler/M2Range.mod (FoldTypeAssign): Avoid error string concatenation. Signed-off-by: Gaius Mulley
[Bug target/79646] Typos in vax.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646 --- Comment #5 from Eric Gallager --- (In reply to Abe from comment #4) > Anybody who wants to chime in, but especially Eric Gallager: please let me > know whether or not my patch looks good enough for submission to the > gcc-patches mailing list, and if not then _why_ not [please]. I think it looks fine to submit; if there are any problems with it, the review will happen there on the mailing list
[Bug gcov-profile/114851] Alternative to -Wmisexpect from LLVM in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114851 --- Comment #3 from Alexander Zaitsev --- > Though I do wonder if the "hints" are used instead of the PGO here. We already discussed this question a bit in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112806 . If I understand correctly, no clear answer yet: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112806#c4 .
[Bug gcov-profile/114851] Alternative to -Wmisexpect from LLVM in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114851 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > I don't think GCC has a warning (yet). Though I do wonder if the "hints" are used instead of the PGO here.
[Bug gcov-profile/114851] Alternative to -Wmisexpect from LLVM in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114851 Andrew Pinski changed: What|Removed |Added Blocks||87403 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- I don't think GCC has a warning (yet). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #10 from Jerry DeLisle --- Well the experiment did not work. I think we need to do something a bit more complex. I will asign to myself so it does fall into a crack and get back here as we go. I will consult with others on ideas.
[Bug c++/94753] -undef, c++20 and feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753 --- Comment #5 from Andrew Pinski --- I will change the testcase's comment to be: ``` For C++11+ __cpp_constexpr and __cpp_static_assert GCC define these even with -undef. ``` The feature macros as mentioned by Jonathan, we want them defined almost everywhere including in older versions of C++, my patch still implements that. The comment in the testcase might be confusing since feature macros were not in C++11 but we should still define them for C++11.
[Bug c++/94753] -undef, c++20 and feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753 --- Comment #4 from Jonathan Wakely --- Maybe I've misunderstood you, but the feature test macros for C++11 features should definitely be defined for C++11. They're not "system-specific" or "GCC-specific". Just because they weren't in the standard prior to C++20 doesn't mean they shouldn't be defined when the corresponding feature is supported.
[Bug c++/114844] A trivial but noexcept(false) destructor is incorrectly considered non-throwing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114844 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- This reminds me of my old patch: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00311.html this sounds like the problem I hit when working on the patch.
[Bug tree-optimization/114853] Inefficient code with a bunch of bitwise checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed||2024-04-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > possibly switch-conversion related iftoswitch does not get invoked here but maybe it should ... I will note that for aarch64, clang/LLVM is able to vectorize this function. But not for x86_64.
[Bug c++/114854] [11/12/13/14 Regression] checking ICE with default initializer of const reference member at cp/cp-gimplify.cc:900 since r10-5822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114854 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org Priority|P3 |P2
[Bug tree-optimization/114853] Inefficient code with a bunch of bitwise checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853 --- Comment #2 from Andrew Pinski --- Created attachment 58040 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58040=edit testcase Please next time, attach (or place inline) the testcase and not just link to godbolt.
[Bug fortran/113885] [13 Regression] ice in gimplify_expr, at gimplify.cc:18658 with finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885 Paul Thomas changed: What|Removed |Added Summary|[13/14 Regression] ice in |[13 Regression] ice in |gimplify_expr, at |gimplify_expr, at |gimplify.cc:18658 with |gimplify.cc:18658 with |finalization|finalization --- Comment #4 from Paul Thomas --- Updated summary Paul
[Bug target/114837] [11/12/13] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 Richard Ball changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Ball --- Fixed
[Bug target/114837] [11/12/13] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #7 from Richard Ball --- Backported to gcc-11, gcc-12 and gcc-13
[Bug target/114837] [11/12/13] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #6 from GCC Commits --- The releases/gcc-11 branch has been updated by Richard Ball : https://gcc.gnu.org/g:dabd742cc25f8992c24e639510df0965dbf14f21 commit r11-11364-gdabd742cc25f8992c24e639510df0965dbf14f21 Author: Richard Ball Date: Thu Apr 25 15:30:42 2024 +0100 arm: Zero/Sign extends for CMSE security Co-Authored by: Andre Simoes Dias Vieira This patch makes the following changes: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits that is passed in a register is zero- or sign-extended. This patch addresses the following CVE-2024-0151. gcc/ChangeLog: PR target/114837 * config/arm/arm.c (cmse_nonsecure_call_inline_register_clear): Add zero/sign extend. (arm_expand_prologue): Add zero/sign extend. gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/extend-param.c: New test. * gcc.target/arm/cmse/extend-return.c: New test. (cherry picked from commit ad45086178d833254d66fab518b14234418f002b)
[Bug fortran/99183] [11 Regression] Incompatible Runtime types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Paul Thomas --- > As soon as regtesting is finished, I will push and close. > > Cheers > > Paul The original PR for this was 102745, which was also fixed on 11-branch :-) Closing as RESOLVED/FIXED Paul
[Bug target/114837] [11/12/13] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Ball : https://gcc.gnu.org/g:441e194abcf3211de647d74c892f90879ae9ca8c commit r12-10394-g441e194abcf3211de647d74c892f90879ae9ca8c Author: Richard Ball Date: Thu Apr 25 15:30:42 2024 +0100 arm: Zero/Sign extends for CMSE security Co-Authored by: Andre Simoes Dias Vieira This patch makes the following changes: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits that is passed in a register is zero- or sign-extended. This patch addresses the following CVE-2024-0151. gcc/ChangeLog: PR target/114837 * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear): Add zero/sign extend. (arm_expand_prologue): Add zero/sign extend. gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/extend-param.c: New test. * gcc.target/arm/cmse/extend-return.c: New test. (cherry picked from commit ad45086178d833254d66fab518b14234418f002b)
[Bug target/114837] [11/12/13] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Ball : https://gcc.gnu.org/g:5550214b58e95320b54e42ef0e37c6479e04b27b commit r13-8647-g5550214b58e95320b54e42ef0e37c6479e04b27b Author: Richard Ball Date: Thu Apr 25 15:30:42 2024 +0100 arm: Zero/Sign extends for CMSE security Co-Authored by: Andre Simoes Dias Vieira This patch makes the following changes: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits that is passed in a register is zero- or sign-extended. This patch addresses the following CVE-2024-0151. gcc/ChangeLog: PR target/114837 * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear): Add zero/sign extend. (arm_expand_prologue): Add zero/sign extend. gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/extend-param.c: New test. * gcc.target/arm/cmse/extend-return.c: New test. (cherry picked from commit ad45086178d833254d66fab518b14234418f002b)
[Bug target/114837] [11/12/13/14] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #3 from Richard Ball --- Fixed on Trunk so far
[Bug target/114837] [11/12/13/14] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Ball : https://gcc.gnu.org/g:ad45086178d833254d66fab518b14234418f002b commit r14-10122-gad45086178d833254d66fab518b14234418f002b Author: Richard Ball Date: Thu Apr 25 15:30:42 2024 +0100 arm: Zero/Sign extends for CMSE security Co-Authored by: Andre Simoes Dias Vieira This patch makes the following changes: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits that is passed in a register is zero- or sign-extended. This patch addresses the following CVE-2024-0151. gcc/ChangeLog: PR target/114837 * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear): Add zero/sign extend. (arm_expand_prologue): Add zero/sign extend. gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/extend-param.c: New test. * gcc.target/arm/cmse/extend-return.c: New test.
[Bug c++/114854] [11/12/13/14 Regression] checking ICE with default initializer of const reference member at cp/cp-gimplify.cc:900 since r10-5822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114854 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Last reconfirmed||2024-04-25 Summary|[14 Regression] ICE with|[11/12/13/14 Regression] |default initializer of |checking ICE with default |const reference member at |initializer of const |cp/cp-gimplify.cc:900 |reference member at ||cp/cp-gimplify.cc:900 since ||r10-5822 Keywords||ice-checking Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |11.5 --- Comment #1 from Patrick Palka --- Confirmed. This checking assert failure started ever since the introduction of the assert, r10-5822-g08f594eb399dab.
[Bug fortran/95682] [11/12 Regression] Default assignment fails with allocatable array of deferred-length strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95682 Paul Thomas changed: What|Removed |Added Resolution|--- |WONTFIX CC||pault at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #8 from Paul Thomas --- (In reply to anlauf from comment #2) > Adding some printout after initializing the t1%x(:), > > do i = 1, size(t1%x) > print *, len_trim (t1%x(i)), t1%x(i) > end do > > I get for gcc-8: > >5 three >5 three >5 three > > and for 9,10,11: > >3 one >3 two >5 three > > That's not a typical regression, but rather wrong code replaced by other > wrong > code. Since this was not really a regression, as you remark, and the testcase works correctly from 12-branch through mainline, I am closing as a WONTFIX. Paul
[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #10 from Robin Dapp --- Yes it helps. Great that get_gimple_for_ssa_name is right below get_rtx_for_ssa_name that I stepped through several times while debugging and I didn't realize the connection, g. But thanks! Good thing it can be solved like that. I cannot do a bootstrap/regtest for aarch64 because cfarm185 is almost out of disk space. As the bug is old and very unlikely to trigger it can surely wait for GCC15?
[Bug fortran/99183] [11 Regression] Incompatible Runtime types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #8 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #4) > > This seems to have been fixed between r12-4097 and r12-4638. > > Duplicate of pr102745, fixed by r12-4464? Yes, indeed. It applies cleanly to 11-branch and fixes the problem. As soon as regtesting is finished, I will push and close. Cheers Paul
[Bug c++/114854] New: [14 Regression] ICE with default initializer of const reference member at cp/cp-gimplify.cc:900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114854
Bug ID: 114854
Summary: [14 Regression] ICE with default initializer of const
reference member at cp/cp-gimplify.cc:900
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dani at danielbertalan dot dev
Target Milestone: ---
Compiling the following code results in an internal compiler error when using
GCC 14 trunk (gcc-14-10094-g0c8e99e5c32). GCC 13.2 is fine with it.
class Vector {
long m_size;
};
struct ProcessSpawnOptions {
Vector const _actions {};
};
void spawn(ProcessSpawnOptions);
void test() { spawn({}); }
: In function 'void test()':
:9:20: internal compiler error: in cp_gimplify_expr, at
cp/cp-gimplify.cc:900
9 | void test() { spawn({}); }
| ~^~~~
Godbolt: https://ice.godbolt.org/z/zP3K37476
[Bug tree-optimization/114853] Inefficient code with a bunch of bitwise checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853 Richard Biener changed: What|Removed |Added Component|c++ |tree-optimization Keywords||missed-optimization --- Comment #1 from Richard Biener --- possibly switch-conversion related
[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #9 from Richard Biener ---
(In reply to Robin Dapp from comment #8)
> Created attachment 58037 [details]
> Expand dump
>
> Dump attached. Insn 209 is the problematic one.
> The changing from _911 to 1078 happens in internal-fn.cc:expand_call_mem_ref
> (and not via TER).
> The lookup there is simple and I was also wondering if there is some
> single_imm_use or so missing.
Nah, it's invalid to do that. You have to use get_gimple_for_ssa_name instead
and handle a NULL return. Alternatively the code could check for
no SSA use on the def (to catch _1 = ).
So the error is in r8-6047-g65dd1346027bb5 which makes it a quite old
wrong-code issue. And yes, Richard S. wrote that.
Can you check if the following fixes the issue? (untested besides compiling
it)
diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
index 2c764441cde..0a7053c2286 100644
--- a/gcc/internal-fn.cc
+++ b/gcc/internal-fn.cc
@@ -53,6 +53,8 @@ along with GCC; see the file COPYING3. If not see
#include "rtl-iter.h"
#include "gimple-range.h"
#include "fold-const-call.h"
+#include "tree-ssa-live.h"
+#include "tree-outof-ssa.h"
/* For lang_hooks.types.type_for_mode. */
#include "langhooks.h"
@@ -2964,8 +2966,8 @@ expand_call_mem_ref (tree type, gcall *stmt, int index)
tree tmp = addr;
if (TREE_CODE (tmp) == SSA_NAME)
{
- gimple *def = SSA_NAME_DEF_STMT (tmp);
- if (gimple_assign_single_p (def))
+ gimple *def = get_gimple_for_ssa_name (tmp);
+ if (def && gimple_assign_single_p (def))
tmp = gimple_assign_rhs1 (def);
}
[Bug tree-optimization/114792] [14 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-copy-prop" on x86_64-linux-gnu: in get_loop_body, at cfgloop.cc:903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug tree-optimization/114792] [14 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-copy-prop" on x86_64-linux-gnu: in get_loop_body, at cfgloop.cc:903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792 --- Comment #7 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:59ff81835fee22a9d4c9a481a4d1814583aae945 commit r14-10120-g59ff81835fee22a9d4c9a481a4d1814583aae945 Author: Richard Biener Date: Thu Apr 25 08:08:24 2024 +0200 tree-optimization/114792 - order loops to unloops in CH When we use unloop_loops we have to make sure to have loops ordered inner to outer as otherwise we can wreck inner loop structure where unlooping relies on that being intact. The following re-sorts the vector of to unloop loops after copy-header as that adds to the vector in two places and the wrong order. PR tree-optimization/114792 * tree-ssa-loop-ch.cc (ch_order_loops): New function. (ch_base::copy_headers): Sort loops to unloop inner-to-outer. * gcc.dg/torture/pr114792.c: New testcase.
[Bug c++/114853] New: Inefficient code with a bunch of bitwise checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114853 Bug ID: 114853 Summary: Inefficient code with a bunch of bitwise checks Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gh228df at gmail dot com Target Milestone: --- Here is a compiler explorer link https://godbolt.org/z/WccxhnTfK, the first function is 'inefficient' while the second function does the same while having 1/2 assembly lines of the first function and will probably run faster in some cases. The problem is that the compiler doesnt generate negated constant once in the start but rather keeps generating it over and over again before every check which is very inefficient
[Bug middle-end/114852] New: jpegxl 10.0.1 is faster with clang18 then with gcc14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114852 Bug ID: 114852 Summary: jpegxl 10.0.1 is faster with clang18 then with gcc14 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- https://www.phoronix.com/review/gcc14-clang18-amd-zen4/3 reports about 8% difference. I can measure 13% on zen3. The code has changed and it is no longer bound by push_back but runs AVX2 version of inner loops. The hottest loops looks comparable 0.00 │266:┌─→vmovaps (%r14,%rax,4),%ymm0 0.11 ││ vmulps (%rcx,%rax,4),%ymm7,%ymm2 1.18 ││ vfnmadd213ps (%rsi,%rax,4),%ymm11,%ymm0 0.25 ││ vmulps %ymm2,%ymm0,%ymm0 5.94 ││ vroundps $0x8,%ymm0,%ymm2 0.35 ││ vsubps %ymm2,%ymm0,%ymm0 1.05 ││ vmulps (%rdx,%rax,4),%ymm0,%ymm0 3.19 ││ vmovaps %ymm0,0x0(%r13,%rax,4) 0.15 ││ vandps %ymm10,%ymm2,%ymm0 0.03 ││ add $0x8,%rax 0.03 ││ vcmpeqps %ymm8,%ymm0,%ymm2 0.09 ││ vsqrtps %ymm0,%ymm0 27.25 ││ vaddps %ymm0,%ymm6,%ymm6 0.35 ││ vandnps %ymm9,%ymm2,%ymm0 0.12 ││ vaddps %ymm0,%ymm5,%ymm5 0.05 │├──cmp %r12,%rax 0.02 │└──jb 266 and clang 0.00 │ c90:┌─→vmulps (%r9,%rdx,4),%ymm0,%ymm2 0.97 │ │ vmovaps (%r15,%rdx,4),%ymm1 0.36 │ │ vsubps %ymm2,%ymm1,%ymm1 4.24 │ │ vmulps (%rcx,%rdx,4),%ymm4,%ymm2 1.92 │ │ vmulps %ymm2,%ymm1,%ymm1 0.65 │ │ vroundps $0x8,%ymm1,%ymm2 0.06 │ │ vsubps %ymm2,%ymm1,%ymm1 1.11 │ │ vmulps (%rax,%rdx,4),%ymm1,%ymm1 3.53 │ │ vmovaps %ymm1,(%rsi,%rdx,4) 0.68 │ │ vandps %ymm6,%ymm2,%ymm1 0.23 │ │ vcmpneqps%ymm5,%ymm2,%ymm2 3.64 │ │ add $0x8,%rdx 0.24 │ │ vsqrtps %ymm1,%ymm1 22.16 │ │ vaddps %ymm1,%ymm8,%ymm8 0.25 │ │ vbroadcastss 0x31eba5(%rip),%ymm1# 34f840 0.05 │ │ vandps %ymm1,%ymm2,%ymm1 0.04 │ │ vaddps %ymm1,%ymm7,%ymm7 0.11 │ ├──cmp %rdi,%rdx 0.07 │ └──jb c90▒ GCC profile: 10.78% cjxl libjxl.so.0.10.1 [.] jxl::N_AVX2::EstimateEntropy(jxl::AcStrategy const&, float, unsigned long, unsigned long, jxl::ACSConfig const&, float con 7.02% cjxl libjxl.so.0.10.1 [.] jxl::N_AVX2::FindBestMultiplier(float const*, float const*, unsigned long, float, float, bool) [clone .part.0] 4.50% cjxl libjxl.so.0.10.1 [.] void jxl::N_AVX2::Symmetric5Row(jxl::Plane const&, jxl::RectT const&, long, jxl: 4.47% cjxl libjxl.so.0.10.1 [.] jxl::N_AVX2::(anonymous namespace)::TransformFromPixels(jxl::AcStrategy::Type, float const*, unsigned long, float*, float* 4.31% cjxl libjxl.so.0.10.1 [.] jxl::N_AVX2::(anonymous namespace)::TransformToPixels(jxl::AcStrategy::Type, float*, float*, unsigned long, float*) 4.00% cjxl libjxl.so.0.10.1 [.] jxl::ThreadPool::RunCallState const&, int const* restrict*, jxl::AcStra 3.56% cjxl libm.so.6 [.] __ieee754_pow_fma 3.49% cjxl libjxl.so.0.10.1 [.] jxl::N_AVX2::(anonymous namespace)::IDCT1DImpl<8ul, 8ul>::operator()(float const*, unsigned long, float*, unsigned long, f 3.43% cjxl libjxl.so.0.10.1 [.] jxl::N_AVX2::(anonymous namespace)::AdaptiveQuantizationImpl::ComputeTile(float, float, jxl::Image3 const&, jxl::Re 3.27% cjxl libjxl.so.0.10.1 [.] void jxl::N_AVX2::(anonymous namespace)::DCT1DWrapper<32ul, 0ul, jxl::N_AVX2::(anonymous namespace)::DCTFrom, jxl::N_AVX2: 3.16% cjxl libjxl.so.0.10.1 [.] jxl::N_AVX2::(anonymous namespace)::DCT1DImpl<8ul, 8ul>::operator()(float*, float*) [clone .isra.0] 2.87% cjxl libjxl.so.0.10.1 [.] void jxl::N_AVX2::(anonymous namespace)::ComputeScaledIDCT<4ul, 8ul>::operator()::operator()::operator() const&, jxl::RectT const&, jxl::DequantMatrices const&, jxl::AcStrategyImage const*, jxl::Plane const*, jxl::Quantizer const*, jxl::Rect▒ 5.03% cjxl libjxl.so.0.10.1 [.] jxl::ThreadPool::RunCallState const&, jxl::RectT const&, jxl::WeightsSymmetric5 const&, jxl::ThreadPool*, jxl::Pla▒ 4.66% cjxl libjxl.so.0.10.1 [.] jxl::N_AVX2::(anonymous namespace)::DCT1DImpl<16ul, 8ul>::operator()(float*, float*) ▒ 4.56% cjxl libjxl.so.0.10.1 [.]
[Bug c++/94753] -undef, c++20 and feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753 --- Comment #3 from r_new at rambler dot ru --- Don't know gcc code, but /* For C++11+ __cpp_constexpr and __cpp_static_assert should be defined. */ #if __cplusplus >= 201103L is not true. All standard predefined macros listed in chapter "16.8 Predefined macro names" C++11 standard. But for C++20 it's true.
[Bug fortran/114467] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114467 thomas changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #5 from thomas --- (In reply to anlauf from comment #4) I have downloaded a recent snapshot, which turned out to be v. 14.0.1 rather than the latest 13-branch. But I can confirm that the problem does not occur anymore when using gfortran v. 14.0.1. Many thanks for your kind help!
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 --- Comment #9 from Matt Thompson --- Jerry, I tried your patch, but it didn't seem to help my reproducer. Stock GCC13: Number of Modules | Build Time - | -- 10 | 0.336674 20 |2.34525 30 |7.37042 40 |17.2896 50 |33.9653 GCC13 with Jerry Patch: Number of Modules | Build Time - | -- 10 | 0.378347 20 |2.51914 30 |8.10597 40 | 18.982 50 |37.3188
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #22 from Jakub Kulik --- Eric and Rainer, thank you both very much for all that testing and the fix.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #21 from Eric Botcazou --- Fixed on Solaris for GCC 14 and later.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #20 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:1d238c84025aaef1641e4000bd2a8f4328b474dd commit r14-10119-g1d238c84025aaef1641e4000bd2a8f4328b474dd Author: Eric Botcazou Date: Thu Apr 25 12:44:14 2024 +0200 Fix calling convention incompatibility with vendor compiler For the 20th anniversary of https://gcc.gnu.org/gcc-3.4/sparc-abi.html, a new calling convention incompatibility with the vendor compiler (and the ABI) has been discovered in 64-bit mode, affecting small structures containing arrays of floating-point components. The decision has been made to fix it on Solaris only at this point. gcc/ PR target/114416 * config/sparc/sparc.h (SUN_V9_ABI_COMPATIBILITY): New macro. * config/sparc/sol2.h (SUN_V9_ABI_COMPATIBILITY): Redefine it. * config/sparc/sparc.cc (fp_type_for_abi): New predicate. (traverse_record_type): Use it to spot floating-point types. (compute_fp_layout): Also deal with array types. gcc/testsuite/ * gcc.target/sparc/small-struct-1.c: New test. * gcc.target/sparc/pr105573.c: Rename to... * gcc.target/sparc/20230425-1.c: ...this. * gcc.target/sparc/pr109541.c: Rename to... * gcc.target/sparc/20230607-1.c: ...this
[Bug c++/105841] [12 Regression] Change in behavior of CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841 --- Comment #17 from Haojian Wu --- > IIRC we didn't want to commit to an API for the built-in, and we also didn't > have any motivating use cases for the it within libstdc++. Thanks for the reply. Fair enough.
[Bug target/114714] [RISC-V][RVV] ICE: insn does not satisfy its constraints (postreload)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714 --- Comment #7 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:af7d981ba40f145256f6f6d3409451e8fa647f75 commit r14-10118-gaf7d981ba40f145256f6f6d3409451e8fa647f75 Author: Pan Li Date: Thu Apr 25 15:04:02 2024 +0800 RISC-V: Add test cases for insn does not satisfy its constraints [PR114714] We have one ICE when RVV register overlap is enabled. We reverted this feature as it is in stage 4 and there is no much time to figure a better solution for this. Thus, for now add the related test cases which will trigger ICE when register overlap enabled. This will gate the RVV register overlap support in GCC-15. PR target/114714 gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/base/pr114714-1.C: New test. * g++.target/riscv/rvv/base/pr114714-2.C: New test. Signed-off-by: Pan Li Co-Authored-by: Kito Cheng
[Bug gcov-profile/114851] New: Alternative to -Wmisexpect from LLVM in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114851 Bug ID: 114851 Summary: Alternative to -Wmisexpect from LLVM in GCC Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: zamazan4ik at tut dot by Target Milestone: --- LLVM infrastructure supports a diagnostic for checking mismatches between user-provided __builtin_expect/[[likely]] hints and PGO profiles: https://clang.llvm.org/docs/DiagnosticsReference.html#wmisexpect + https://llvm.org/docs/MisExpect.html (and an example of its usage in Chromium: https://issues.chromium.org/issues/40694104). I was trying to find a similar diagnostic in GCC but found nothing. Is there anything similar in GCC? If not, can we make the issue a Feature Request for such a feature? Having such a diagnostic can be helpful in practice since it allows for finding wrongfully placed user hints in sources.
[Bug middle-end/114849] Static function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849 --- Comment #4 from Manjunath Bhavimani --- We used same options for both toolchain version. Except linker option -specs=nano.specs, this is not used for v10.3 Compiler Option: -mcpu=cortex-m7 -mthumb -mlittle-endian -mfpu=fpv5-sp-d16 -mfloat-abi=hard -std=c99 -Os -ggdb3 -Wall -Wextra -pedantic -Wstrict-prototypes -Wundef -Wunused -Werror=implicit-function-declaration -Wsign-compare -Wdouble-promotion -fno-short-enums -funsigned-char -funsigned-bitfields -fomit-frame-pointer -fno-common -fstack-usage -fdump-ipa-all -c --sysroot=$(NEWLIB_DIR) -specs=nano.specs -specs=nosys.specs Assembler Option: -xassembler-with-cpp -mcpu=cortex-m7 -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mthumb -c Linker Option: --entry=$(ENTRYSYMBOL) -nostartfiles -mcpu=cortex-m7 -mthumb -mfpu=fpv5-sp-d16 -mfloat-abi=hard -mlittle-endian -ggdb3 -lc -lm -lgcc -specs=nano.specs -specs=nosys.specs --sysroot=$(LIB_DIR)
[Bug target/96866] ICE in print_operand_address, at config/rs6000/rs6000.c:13560
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96866
--- Comment #3 from Jiu Fu Guo ---
While, I'm wondering if we could accept this code, and handle it as something
like:
(insn 5 4 6 (set (reg/f:DI 118)
(mem/u/c:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC0") [flags 0x2])
(reg:DI 2 2)
] UNSPEC_TOCREL) [2 S8 A8])) "t.c":8:8 -1
(expr_list:REG_EQUAL (symbol_ref:DI ("x") [flags 0x80] )
(nil)))
(insn 6 5 0 (parallel [
(asm_operands/v ("#%a0") ("") 0 [
(reg/f:DI 118)
]
[
(asm_input:DI ("X") t.c:9)
]
[] t.c:9)
(clobber (reg:SI 98 ca))
]) "t.c":9:3 -1
(nil))
[Bug target/96866] ICE in print_operand_address, at config/rs6000/rs6000.c:13560
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96866
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #2 from Jiu Fu Guo ---
with -fPIC, the asm insn in RTL looks like:
(insn 8 7 0 (parallel [
(asm_operands/v ("#%a0") ("") 0 [
(symbol_ref:DI ("x") [flags 0x80] )
]
[
(asm_input:DI ("X") t.c:9)
]
[] t.c:9)
(clobber (reg:SI 98 ca))
]) "t.c":9:3 -1
(nil))
Here operand 0 of asm is "(symbol_ref:DI ("x")..)", this is not handled as the
invalid address.
Some targets(e.g. x86_64) report messages (like "invalid constraints for
operand") for this code.
This PR mentions ice-on-invalid-code too :)
[Bug c++/114850] co_await a async function which result type is std::unique_ptr<...> or shared_ptr in a initializer list causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114850 --- Comment #2 from Jeremy Pewterschmidt --- Created attachment 58039 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58039=edit compressed file generated by g++ with -save-temps
[Bug c++/114850] co_await a async function which result type is std::unique_ptr<...> or shared_ptr in a initializer list causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114850 --- Comment #1 from Jeremy Pewterschmidt --- Created attachment 58038 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58038=edit compressed file generated by g++ with -freport-bug
[Bug c++/114850] New: co_await a async function which result type is std::unique_ptr<...> or shared_ptr in a initializer list causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114850
Bug ID: 114850
Summary: co_await a async function which result type is
std::unique_ptr<...> or shared_ptr in a initializer
list causes ICE
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremypewterschmidt at gmail dot com
Target Milestone: ---
I've noticed that there're some reports looks like the same, but I still
decided to report this to give you more information to help to resolve the
problem. But please make sure you read the snippet first.
Related reports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99827
OS: Arch Linux x86_64 with kernel 6.8.7-zen1-1-zen
Although the OS is arch, but I have also tried this code in compiler explorer
with the same version, same options.
message dumped by g++ --version:
g++ (GCC) 13.2.1 20230801
Copyright (C) 2023 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.
command: g++ main.cpp --std=c++20 -freport-bug
Snippet caused the problem:
```c++
#include
#include
#include
//#include
template
struct Task {
struct Awaitable {
std::coroutine_handle<> coroutine;
T result;
bool await_ready() { return false; }
void await_suspend(std::coroutine_handle<> h) { coroutine = h; }
T await_resume() { return ::std::move(result); }
};
struct promise_type {
T value;
auto get_return_object() { return Task{
std::coroutine_handle::from_promise(*this) }; }
auto initial_suspend() { return std::suspend_never{}; }
auto final_suspend() noexcept { return std::suspend_always{}; }
void return_value(T val) { value = ::std::move(val); }
void unhandled_exception() {}
};
std::coroutine_handle coroutine;
Task(std::coroutine_handle coroutine) : coroutine(coroutine)
{}
~Task() noexcept {
if (coroutine)
coroutine.destroy();
}
T getResult() {
return coroutine.promise().value;
}
Awaitable operator co_await() {
return { coroutine, ::std::move(coroutine.promise().value) };
}
};
Task<::std::unique_ptr> uniqueGuy() {
co_return nullptr;
}
Task<::std::shared_ptr> sharedGuy() {
co_return nullptr;
}
//Task<::std::optional> optionalGuy() {
//co_return ::std::optional();
//}
Task intGuy()
{
co_return 0;
}
Task asyncFunction() {
//// OK
//::std::vector iVec{
//co_await intGuy(),
//co_await intGuy(),
//};
//
//// OK
//::std::vector optVec{
//co_await optionalGuy(),
//co_await optionalGuy(),
//};
//// ICE
//::std::vector uniqueVec{
//co_await uniqueGuy(),
//co_await uniqueGuy(),
//};
//
// ICE
::std::vector<::std::unique_ptr> uniqueVec2{
co_await uniqueGuy(),
co_await uniqueGuy(),
};
//// OK
//::std::vector<::std::unique_ptr> uniqueVec3;
//uniqueVec3.push_back(co_await uniqueGuy());
//uniqueVec3.push_back(co_await uniqueGuy());
//// ICE
//::std::vector sharedVec{
//co_await sharedGuy(),
//co_await sharedGuy(),
//};
co_return 0;
}
int main() {
return 0;
}
```
The ICE message:
src/main.cpp: In function ‘Task asyncFunction()’:
src/main.cpp:99:1: internal compiler error: in build_special_member_call, at
cp/call.cc:11093
99 | }
| ^
0x1ad33c8 internal_error(char const*, ...)
???:0
0x6b7b63 fancy_abort(char const*, int, char const*)
???:0
0x10dc463 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc463 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc463 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc463 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc583 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x10dc463 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node*
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #17 from Eric Botcazou --- [...] >>> The sparc64-unknown-linux-gnu one will be running for a couple more >>> hours, though. >> >> The change should be a no-op for this platform. > > True. However, I'd rather wait for the bootstrap to complete. Should > be sometime tonight... That's finished now, too, and as expected there were no regressions.
[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846 --- Comment #2 from Kewen Lin --- As https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843#c8, we may need some similar handling like r14-6440-g4b421728289e6f.
[Bug target/114846] powerpc: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846 Kewen Lin changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-25 Status|UNCONFIRMED |NEW CC||bergner at gcc dot gnu.org, ||linkw at gcc dot gnu.org, ||segher at gcc dot gnu.org Target|powerpc64-linux-gnu |powerpc64*-linux-gnu |powerpc-linux-gnu |powerpc-linux-gnu --- Comment #1 from Kewen Lin --- Thanks for reporting, confirmed, it also fails on LE (ppc64le-linux).
[Bug target/114843] aarch64: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Just an FYI on other targets on my reduced testcase (I just quickly looked > at the generated assembly to see if it worked or not): > > backends that seems to work: > mips > riscv > x86 > s390 > m68k > sh > sparc > > backends that don't work: > powerpc: PR 114846 > arm: PR 114847 > longarch: PR 114848 Looks like longarch was fixed in GCC 14: r14-6440 . Most likely other targets should do something similar ...
[Bug other/114738] [14 Regression] Default DOCUMENTATION_ROOT_URL vs. release branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/114828] [14 Regression] ICE on valid code at -O1 with "-ftree-pre -fselective-scheduling -fsel-sched-pipelining -fschedule-insns" on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114828 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P2
[Bug middle-end/114849] Static function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-04-25 --- Comment #3 from Andrew Pinski --- Can you provide the configure options you used for the 2 compilers? And the exact command that is used to build your test program?
[Bug target/114848] loongarch: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848 --- Comment #4 from Andrew Pinski --- Also it looks like I messed up comment #0 and forgot to change powerpc to longarch64 :). That is what I get for trying to split this all out.
[Bug middle-end/114849] Static function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849 --- Comment #2 from Manjunath Bhavimani --- Yes i am using same ld script, only compiler version changed
[Bug middle-end/114849] Static function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Target||arm-eabi --- Comment #1 from Andrew Pinski --- I wonder if this is a bug in the linker rather than gcc . Are you using the same ld between gcc 10.3 and 10.2?
[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #8 from Robin Dapp --- Created attachment 58037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58037=edit Expand dump Dump attached. Insn 209 is the problematic one. The changing from _911 to 1078 happens in internal-fn.cc:expand_call_mem_ref (and not via TER). The lookup there is simple and I was also wondering if there is some single_imm_use or so missing.
[Bug target/114848] loongarch: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848 Xi Ruoyao changed: What|Removed |Added Summary|longarch: epilogue in |loongarch: epilogue in |_Unwind_RaiseException |_Unwind_RaiseException |corrupts return value due |corrupts return value due |to __builtin_eh_return |to __builtin_eh_return --- Comment #3 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #2) > (In reply to Xi Ruoyao from comment #1) > > Hmm, AFAIK this should be already fixed with r14-6440? > > > > I cannot reproduce it with r14-9823 but maybe it has regressed again in the > > recent weeks. > > Oh I only tested gcc 13.2.0. If it is fixed you can close it. Hmm it looks like we need a backport to releases/gcc-13 (and 12?) I thought the bug was introduced by my shrink-wrap change (r14-545) so I didn't proposed a backport. But it seems I was wrong and the bug exists even before r14-545.
[Bug c/114849] New: Static function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849 Bug ID: 114849 Summary: Static function pointer Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: Manjunath.Bhavimani at elektrobit dot com Target Milestone: --- Created attachment 58036 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58036=edit Zip folder contains snippet and preprocessed *.c files Hi, I am using compiler v10.2 (v10.2_build_b1728_g5963bc8). I observed some suspicious behavior in code compilation. In my code, I have a static function with the same name in three different files (Task1.c, Task2.c, and Task3.c). The static function is accessed through a static volatile function pointer in respective files. The volatile qualifier is added to avoid optimization. Each file has its own dedicated data section in memory. With gcc v10.2, I observed that the data section for all static variables of Task2 file is initialized properly, but not for the other files (Task1 and Task3). As a result, our code crashes when the static function is accessed through the static function pointer. Reason: The static function pointer has an invalid address or is "0". Our observation: When we moved to a higher version of gcc (i.e., v10.3), this issue is not observed. Kindly let us know if this issue is already known. If yes, could you please let us know the right patch version for v10.2? Otherwise, this needs to be fixed in v10.2. Upgrading to the v10.3 toolchain is not within our project scope. I have attached all files and snippets for your reference. Note: I am working on SRAM; no flash is used, hence no data copy operation. With Regards, Manjunath Bhavimani
[Bug target/114848] longarch: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848 Andrew Pinski changed: What|Removed |Added Version|14.0|13.2.0 --- Comment #2 from Andrew Pinski --- (In reply to Xi Ruoyao from comment #1) > Hmm, AFAIK this should be already fixed with r14-6440? > > I cannot reproduce it with r14-9823 but maybe it has regressed again in the > recent weeks. Oh I only tested gcc 13.2.0. If it is fixed you can close it.
[Bug target/114848] longarch: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Hmm, AFAIK this should be already fixed with r14-6440? I cannot reproduce it with r14-9823 but maybe it has regressed again in the recent weeks.
[Bug target/114843] aarch64: epoligue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #7 from Andrew Pinski --- Just an FYI on other targets on my reduced testcase (I just quickly looked at the generated assembly to see if it worked or not): backends that seems to work: mips riscv x86 s390 m68k sh sparc backends that don't work: powerpc: PR 114846 arm: PR 114847 longarch: PR 114848
[Bug target/114843] aarch64: epoligue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #6 from Andrew Pinski --- Note I just happened to finish a build of aarch64 so I was able to create the preprocessed source of unwind-dw2.i really quick. And then I just read the aarch64.cc to see the saving of x0 happened due to __builtin_eh_return . That is how I got a testcase so quickly. If I read the assembly correctly a few other targets are broken too; let me file a bug report for each of them ..
[Bug target/114843] aarch64: epoligue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 Andrew Pinski changed: What|Removed |Added Severity|normal |critical
[Bug target/114843] aarch64: epoligue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 Andrew Pinski changed: What|Removed |Added Summary|AArch64: Wrong Register |aarch64: epoligue in |Reload in |_Unwind_RaiseException |_Unwind_RaiseException |corrupts return value due |causes corrupt return value |to __builtin_eh_return |on _URC_END_OF_STACK| --- Comment #5 from Andrew Pinski --- I suspect this has been always a bug since the aarch64 back-end was added.
[Bug target/114843] AArch64: Wrong Register Reload in _Unwind_RaiseException causes corrupt return value on _URC_END_OF_STACK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-04-25
--- Comment #4 from Andrew Pinski ---
Confirmed reduced runtime self contained testcase:
```
__attribute__((noipa))
int f(int *a, long offset, void *handler)
{
if (*a == 5)
return 5;
__builtin_eh_return (offset, handler);
}
int main()
{
int t = 5;
if (f(, 0, 0) != 5)
__builtin_abort();
}
```
[Bug target/114843] AArch64: Wrong Register Reload in _Unwind_RaiseException causes corrupt return value on _URC_END_OF_STACK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114843 --- Comment #3 from Andrew Pinski --- ((insn 262 261 263 14 (parallel [ (set (reg:DI 0 x0) (unspec:DI [ (mem/c:V2x8QI (plus:DI (reg/f:DI 31 sp) (const_int 16 [0x10])) [0 S16 A8]) ] UNSPEC_LDP_FST)) (set (reg:DI 1 x1) (unspec:DI [ (mem/c:V2x8QI (plus:DI (reg/f:DI 31 sp) (const_int 16 [0x10])) [0 S16 A8]) ] UNSPEC_LDP_SND)) ]) "../../../libgcc/unwind.inc":141:1 -1 (nil)) It is added by pro_and_epilogue for some reason ...
