[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 #5 from chenglulu --- (In reply to Xi Ruoyao from comment #3) > (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 have backpointed r14-6440 to gcc-13 and gcc-12 and am testing > > 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 middle-end/113179] [11/12/13/14/15 Regression] MIPS: INS is used for long long, before SLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179 --- Comment #3 from YunQiang Su --- 36088299955f95ab58a5758cba2f29b84c8fbfbc is the first bad commit commit 36088299955f95ab58a5758cba2f29b84c8fbfbc Author: Richard Biener Date: Wed Jun 29 07:17:57 2016 + match.pd ((T)(T2)x -> (T)x): Remove restriction on final precision not matching mode precision. 2016-07-29 Richard Biener * match.pd ((T)(T2)x -> (T)x): Remove restriction on final precision not matching mode precision. From-SVN: r237838 gcc/ChangeLog | 5 + gcc/match.pd | 11 +++ 2 files changed, 8 insertions(+), 8 deletions(-)
[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #11 from Paul Thomas --- Created attachment 58054 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58054&action=edit Fix for this PR Hi Orion and Jakub, Mea culpa, mea maxima culpa! I had totally overlooked the use of gfc_trans_class_init_assign for application of 'mold' in class allocation. subroutine restore_smoothers(level,save1, save2,info) snip if (allocated(level%sm)) then if (info == 0) call level%sm%free(info) if (info == 0) deallocate(level%sm,stat=info) end if if (allocated(save1)) then if (info == 0) allocate(level%sm,mold=save1,stat=info) ! Repeats below... if (info == 0) call save1%clone_settings(level%sm,info) end if snip the attached patch fixes both this problem and respects the standard for the default initialization of INTENT(OUT) dummies. It regtests fine. A suitable testcase is on its way. @Jakub, As per your message of Fri Apr 26 11:03:31, I hope that the patch can find its way to the 14.1 release candidate. Regards Paul
[Bug fortran/93814] [11/12/13/14/15 Regression] ICE in build_entry_thunks, at fortran/trans-decl.c:2898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93814 --- Comment #12 from David Binderman --- Bit more detail: ./Lower/HLFIR/bindc-entry-stmt.f90:5:0: 5 | function foo() bind(c) Warning: Variable ‘foo’ at (1) may not be a C interoperable kind but it is BIND(C) [-Wc-binding-type] ./Lower/HLFIR/bindc-entry-stmt.f90:39:28: 39 | character(1) :: foo2, bar2 |1 Warning: Variable ‘bar2’ at (1) may not be a C interoperable kind but it is BIND(C) [-Wc-binding-type] ==1442522== Invalid read of size 8 ==1442522==at 0x862E5E: quick_push (vec.h:1043) ==1442522==by 0x862E5E: vec_safe_push (vec.h:835) ==1442522==by 0x862E5E: build_entry_thunks (trans-decl.cc:3002) ==1442522==by 0x862E5E: gfc_create_function_decl(gfc_namespace*, bool) (trans-decl.cc:3157)
[Bug fortran/113917] ice in gfc_class_vptr_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113917 --- Comment #2 from David Binderman --- Bit more detail from valgrind: ==1450005== Invalid read of size 2 ==1450005==at 0x86B811: gfc_class_vptr_get(tree_node*) (trans-expr.cc:247) ==1450005==by 0x883366: trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) (trans-expr.cc:10146) ==1450005==by 0x8863A2: trans_class_assignment (trans-expr.cc:11969) ==1450005==by 0x8863A2: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool, bool, bool) (trans-expr.cc:12435)
[Bug fortran/114871] New: valgrind error in gfc_class_vptr_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114871 Bug ID: 114871 Summary: valgrind error in gfc_class_vptr_get Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- >From the flang test suite at https://github.com/llvm/llvm-project/tree/main/flang/test, the file ./Lower/Intrinsics/spread.f90, does this: $ ~/gcc/results.20240427.valgrind/bin/gfortran -c -w ./Lower/Intrinsics/spread.f90 ==1511945== Invalid read of size 2 ==1511945==at 0x86B811: gfc_class_vptr_get(tree_node*) (trans-expr.cc:247) ==1511945==by 0x883366: trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) (trans-expr.cc:10146) ==1511945==by 0x8863A2: trans_class_assignment (trans-expr.cc:11969) ==1511945==by 0x8863A2: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool, bool, bool) (trans-expr.cc:12435)
[Bug fortran/113917] ice in gfc_class_vptr_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113917 kargls at comcast dot net changed: What|Removed |Added CC||kargls at comcast dot net --- Comment #3 from kargls at comcast dot net --- Reduce testcase. subroutine unlimited_polymorphic_parenthesis(x, y) class(*), allocatable :: x(:) class(*), intent(in) :: y(:) x = (y) end subroutine unlimited_polymorphic_parenthesis
[Bug c/114872] New: Miscompilation with -O2 after commit 049ec9b981d1f4f97736061d5cf7d0ae990b57d7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 Bug ID: 114872 Summary: Miscompilation with -O2 after commit 049ec9b981d1f4f97736061d5cf7d0ae990b57d7 Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: arojas at archlinux dot org Target Milestone: --- Commit 049ec9b981d1f4f97736061d5cf7d0ae990b57d7 is causing some runtime crashes in sagemath when compiled with -O2 or higher (-O1 is fine) The specific affected source file is element.c obtained from cythonizing element.pyx in https://github.com/sagemath/sage/blob/10.4.beta4/src/sage/libs/gap/element.pyx Manual compilation command and output is: > LANG=C gcc -O2 -fPIC -I/usr/lib/python3.12/site-packages/cysignals > -I/usr/lib/python3.12/site-packages/sage/cpython/ -I/usr/include/python3.12 > -c element.c -o element.o -v -save-temps Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.2.1 20231110 (GCC) COLLECT_GCC_OPTIONS='-O2' '-fPIC' '-I' '/usr/lib/python3.12/site-packages/cysignals' '-I' '/usr/lib/python3.12/site-packages/sage/cpython/' '-I' '/usr/include/python3.12' '-c' '-o' 'element.o' '-v' '-save-temps' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/cc1 -E -quiet -v -I /usr/lib/python3.12/site-packages/cysignals -I /usr/lib/python3.12/site-packages/sage/cpython/ -I /usr/include/python3.12 element.c -mtune=generic -march=x86-64 -fPIC -O2 -fpch-preprocess -o element.i ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/python3.12/site-packages/cysignals /usr/lib/python3.12/site-packages/sage/cpython/ /usr/include/python3.12 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-O2' '-fPIC' '-I' '/usr/lib/python3.12/site-packages/cysignals' '-I' '/usr/lib/python3.12/site-packages/sage/cpython/' '-I' '/usr/include/python3.12' '-c' '-o' 'element.o' '-v' '-save-temps' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/cc1 -fpreprocessed element.i -quiet -dumpbase element.c -dumpbase-ext .c -mtune=generic -march=x86-64 -O2 -version -fPIC -o element.s GNU C17 (GCC) version 13.2.1 20231110 (x86_64-pc-linux-gnu) compiled by GNU C version 13.2.1 20231110, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 45f88f2c66186490486270a091963f0f element.c: In function '__pyx_f_4sage_4libs_3gap_7element_10GapElement__type_number': element.c:12020:16: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 12020 | __pyx_v_name = TNAM_OBJ(__pyx_v_self->value); |^ COLLECT_GCC_OPTIONS='-O2' '-fPIC' '-I' '/usr/lib/python3.12/site-packages/cysignals' '-I' '/usr/lib/python3.12/site-packages/sage/cpython/' '-I' '/usr/include/python3.12' '-c' '-o' 'element.o' '-v' '-save-temps' '-mtune=generic' '-march=x86-64' as -v -I /usr/lib/python3.12/site-packages/cysignals -I /usr/lib/python3.12/site-packages/sage/cpython/ -I /usr/include/python3.12 --64 -o element.o element.s GNU assembler version 2.42.0 (x86_64-pc-linux-gnu) using BFD version (GNU Binutils) 2.42.0 COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-O2' '-fPIC' '-I' '/usr/lib/python3.12/site-packages/cysignals'
[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 --- Comment #12 from Jakub Jelinek --- There is still time, probably until Tuesday morning, so if it is committed say by Monday to trunk, it can be cherry-picked then. I'd prefer to see the whole patch before acking it for 14.1, possibly even build a test rpm which could verify if the package now works again.
[Bug c/114872] Miscompilation with -O2 after commit 049ec9b981d1f4f97736061d5cf7d0ae990b57d7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #1 from Antonio Rojas --- Created attachment 58055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58055&action=edit output of gcc -save-temps
[Bug c/114872] Miscompilation with -O2 after commit 049ec9b981d1f4f97736061d5cf7d0ae990b57d7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #2 from Andrew Pinski --- g:049ec9b981d1f4f97736061d5cf7d0ae990b57d7
[Bug c/114872] Miscompilation with -O2 after commit 049ec9b981d1f4f97736061d5cf7d0ae990b57d7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #3 from Andrew Pinski --- Does -fno-strict-aliasing help?
[Bug c/114872] Miscompilation with -O2 after commit 049ec9b981d1f4f97736061d5cf7d0ae990b57d7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #4 from Antonio Rojas --- (In reply to Andrew Pinski from comment #3) > Does -fno-strict-aliasing help? No, same result.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #8 from anlauf at gcc dot gnu.org --- Created attachment 58056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58056&action=edit Patch part 2. This part fixes the array case. Needs further testing.
[Bug c++/105760] [11/12/13/14/15 Regression] ICE: in build_function_type, at tree.cc:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760 Simon Martin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |simartin at gcc dot gnu.org --- Comment #3 from Simon Martin --- Working on this one...
[Bug c++/105760] [11/12/13/14/15 Regression] ICE: in build_function_type, at tree.cc:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760 Simon Martin changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3 Summary|Miscompilation with -O2 |[13/14/15 Regression] |after commit r13-8037 |Miscompilation with -O2 ||after commit r13-8037 Known to fail||13.2.1 Known to work||13.2.0
[Bug c/114873] New: Incorrect warning generated for [*] array when in atomic or typeof type specifier for a parameter declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873 Bug ID: 114873 Summary: Incorrect warning generated for [*] array when in atomic or typeof type specifier for a parameter declaration 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 generates warnings for [*] arrays when in an atomic or type specifier even if it is part of a parameter declaration for example: void foo(typeof(int(*)[*])(*)[*]); void bar(_Atomic(int(*)[*])(*)[*]); These generate warnings (saying that '[*]' not in a declaration) when they should be fine. They should be equivalent to: void foo(int(*(*)[*])[*]); void bar(int(*_Atomic(*)[*])[*]); Which generate no warnings.
[Bug c/114873] Incorrect warning generated for [*] array when in atomic or typeof type specifier for a parameter declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873 --- Comment #1 from Andrew Pinski --- clang errors out: :3:24: error: star modifier used outside of function prototype 3 | void bar(_Atomic(int(*)[*])(*)[*]); |^ :3:30: error: a type specifier is required for all declarations 3 | void bar(_Atomic(int(*)[*])(*)[*]); | ^
[Bug c/114873] Incorrect warning generated for [*] array when in atomic or typeof type specifier for a parameter declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873 --- Comment #2 from Andrew Pinski --- So does ICC (EDG): (3): error: variable length array with unspecified bound is not allowed void bar(_Atomic(int(*)[*])(*)[*]); ^
[Bug c/114873] Incorrect warning generated for [*] array when in atomic or typeof type specifier for a parameter declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873 --- Comment #3 from Halalaluyafail3 --- (In reply to Andrew Pinski from comment #1) > clang errors out: > :3:24: error: star modifier used outside of function prototype > 3 | void bar(_Atomic(int(*)[*])(*)[*]); > |^ > :3:30: error: a type specifier is required for all declarations > 3 | void bar(_Atomic(int(*)[*])(*)[*]); > | ^ I made a bug report for Clang earlier today about this: https://github.com/llvm/llvm-project/issues/90348.
[Bug fortran/114874] New: [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 Bug ID: 114874 Summary: [14/15 Regression] ICE with select type, type is (character(*)), and substring Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- The following code fails for me with latest 14-branch/15-release candidate: program p implicit none class(*), allocatable :: c c = 'abc' select type (c) type is (character(*)) print *, c print *, c(2:2) ! ICE end select end p __copy_character_1hhh.f90:8:22: 8 | print *, c(2:2) ! ICE | 1 internal compiler error: Segmentation fault 0x10c6f6f crash_signal ../../gcc-14/gcc/toplev.cc:319 0xa7e6f1 gfc_conv_scalarized_array_ref ../../gcc-14/gcc/fortran/trans-array.cc:3938 0xa7f596 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc-14/gcc/fortran/trans-array.cc:4094 0xac25ea gfc_conv_variable ../../gcc-14/gcc/fortran/trans-expr.cc:3181 0xac5be2 gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc-14/gcc/fortran/trans-expr.cc:9935 0xaf00b6 gfc_trans_transfer(gfc_code*) ../../gcc-14/gcc/fortran/trans-io.cc:2609 0xa73157 trans_code ../../gcc-14/gcc/fortran/trans.cc:2583 0xaed036 build_dt ../../gcc-14/gcc/fortran/trans-io.cc:2053 0xa73177 trans_code ../../gcc-14/gcc/fortran/trans.cc:2555 0xb1471f gfc_trans_block_construct(gfc_code*) ../../gcc-14/gcc/fortran/trans-stmt.cc:2377 0xa73337 trans_code ../../gcc-14/gcc/fortran/trans.cc:2459 0xb0abf7 gfc_trans_select_type_cases ../../gcc-14/gcc/fortran/trans-stmt.cc:3020 0xb15ff4 gfc_trans_select_type(gfc_code*) ../../gcc-14/gcc/fortran/trans-stmt.cc:3729 0xa730a7 trans_code ../../gcc-14/gcc/fortran/trans.cc:2479 0xb1471f gfc_trans_block_construct(gfc_code*) ../../gcc-14/gcc/fortran/trans-stmt.cc:2377 0xa73337 trans_code ../../gcc-14/gcc/fortran/trans.cc:2459 0xaa8ed1 gfc_generate_function_code(gfc_namespace*) ../../gcc-14/gcc/fortran/trans-decl.cc:7880 0xa1b65f translate_all_program_units ../../gcc-14/gcc/fortran/parse.cc:7099 0xa1b65f gfc_parse_file() ../../gcc-14/gcc/fortran/parse.cc:7413 0xa6fe7f gfc_be_parse_file ../../gcc-14/gcc/fortran/f95-lang.cc:241
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||10.5.0, 11.4.1, 12.3.1, ||13.2.1 Keywords||ice-on-valid-code Priority|P3 |P4
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 --- Comment #1 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #0) > The following code fails for me with latest 14-branch/15-release candidate: Oops, I meant: 14-release candidate/15-mainline after branching...
[Bug target/113822] aarch64_evpc_reencode could/should use new_shrunk_vector instead of manually doing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:f91569e779041e2723be23d31c2a79f1861efc7f commit r15-12-gf91569e779041e2723be23d31c2a79f1861efc7f Author: Andrew Pinski Date: Mon Feb 12 15:48:48 2024 -0800 aarch64: Use vec_perm_indices::new_shrunk_vector in aarch64_evpc_reencode While working on PERM related stuff, I can across that aarch64_evpc_reencode was manually figuring out if we shrink the perm indices instead of using vec_perm_indices::new_shrunk_vector; shrunk was added after reencode was added. Built and tested for aarch64-linux-gnu with no regressions. gcc/ChangeLog: PR target/113822 * config/aarch64/aarch64.cc (aarch64_evpc_reencode): Use vec_perm_indices::new_shrunk_vector instead of manually going through the indices. Signed-off-by: Andrew Pinski
[Bug target/113822] aarch64_evpc_reencode could/should use new_shrunk_vector instead of manually doing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug c++/114858] [11/12/13/14/15 regression] Compilation Hang and Excessive RAM Consumption in GCC with invalid input since r0-128725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858 --- Comment #3 from Hans-Peter Nilsson --- Looks like it slowly chews up memory. I killed an -O2 run when cc1plus had consumed 110 GiB, x86_64-linux at r14-10114-g09680e3ee7d7.
[Bug go/114875] New: runtime/runtime.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875 Bug ID: 114875 Summary: runtime/runtime.h Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: jeffrey.cliff at gmail dot com Target Milestone: ---
[Bug go/114875] runtime/runtime.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-04-28 --- Comment #1 from Andrew Pinski --- There is no comment on what is the issue here ...
[Bug c++/109648] ICE: tree check: expected type_pack_expansion or expr_pack_expansion, have error_mark in tsubst_pack_expansion, at cp/pt.cc:13551 since r13-272-gdc6c96f0707aba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109648
Kacper Słomiński changed:
What|Removed |Added
CC||kacper.slominski72 at gmail
dot co
||m
--- Comment #2 from Kacper Słomiński ---
Different test case with the same ICE:
int foo(auto...) { return 0; }
template
void bar() {
[]() {
return foo(({ Us{}; 1; })...);
}.template operator()();
}
int main() {
bar();
}
[Bug target/95782] [s390] ICE in _cpp_pop_context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95782 --- Comment #4 from GCC Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:83bc41e8364360b63eaa59c88e2fb499a6751233 commit r15-14-g83bc41e8364360b63eaa59c88e2fb499a6751233 Author: Jiufu Guo Date: Wed Mar 27 14:15:40 2024 +0800 s390: avoid peeking eof after __vector Same like PR101168, it is need for s390 to avoid peeking eof after vector keyword. And similar test case is also ok for s390. PR target/95782 gcc/ChangeLog: * config/s390/s390-c.cc (s390_macro_to_expand): Avoid empty identifier. gcc/testsuite/ChangeLog: * g++.target/s390/pr95782.C: New test.
[Bug go/114875] runtime/runtime.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875
--- Comment #2 from jeffrey.cliff at gmail dot com ---
whoops, accidentally hit submit before I had all the details
tl;dr at least in gcc 14.1 [but probably elsewhere]
in
libgo/runtime/runtime.h
defines an enum of
enum
{
true= 1,
false = 0,
};
which means that it doesn't compile under -std=gnu2x similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114216
and more importantly - it's a header, which means *any code that uses it* also
won't build.
it's an easy enough fix
add an if guard
#if __STDC_VERSION__ <= 201710L
enum
{
true= 1,
false = 0,
};
#endif
this allows for runtime/runtime.h to be compliant with c23 and previous
versions.
testing the fix now
[Bug go/114875] runtime/runtime.h should be updated to compile under C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|WAITING |NEW Summary|runtime/runtime.h |runtime/runtime.h should be ||updated to compile under ||C23 --- Comment #3 from Andrew Pinski --- Considering this file is written in C11 (or C17), the changes does not need to happen right away.
[Bug go/114875] runtime/runtime.h should be updated to compile under C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875 --- Comment #4 from Andrew Pinski --- (In reply to jeffrey.cliff from comment #2) > and more importantly - it's a header, which means *any code that uses it* > also won't build. Considering it is an internal header to libgo and not installed, it just means any code that uses it must be written in C11/C17 rather than C23.
[Bug go/114875] runtime/runtime.h should be updated to compile under C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875 --- Comment #5 from Andrew Pinski --- Also it is not just true/false. It is: typedef _Bool bool; The rest looks ok too.
[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 Paul Thomas changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #13 from Paul Thomas --- (In reply to Jakub Jelinek from comment #12) > There is still time, probably until Tuesday morning, so if it is committed > say by Monday to trunk, it can be cherry-picked then. I'd prefer to see the > whole patch before acking it for 14.1, possibly even build a test rpm which > could verify if the package now works again. OK - I am on to it. Thanks Paul @Harald - I will submit to the list a bit later on and, hopefully, will commit tonight.
[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #17 from Li Pan --- According to the V abi, looks like the asm code tries to save/restore the callee-saved registers when there is a call in function body. | Name| ABI Mnemonic | Meaning | Preserved across calls? = | v0 | | Argument register| No | v1-v7 | | Callee-saved registers | Yes | v8-v23 | | Argument registers | No | v24-v31 | | Callee-saved registers | Yes
[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639 --- Comment #18 from JuzheZhong --- (In reply to Li Pan from comment #17) > According to the V abi, looks like the asm code tries to save/restore the > callee-saved registers when there is a call in function body. > > | Name| ABI Mnemonic | Meaning | Preserved across > calls? > = > > | v0 | | Argument register| No > | v1-v7 | | Callee-saved registers | Yes > | v8-v23 | | Argument registers | No > | v24-v31 | | Callee-saved registers | Yes I see, https://godbolt.org/z/7bx1EEdGn When we use 44 instead of get_vl (), the load/store instructions are gone.
[Bug target/114639] [riscv] ICE in create_pre_exit, at mode-switching.cc:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #19 from Li Pan ---
Thanks Juzhe. Here is another example
-
#include
extern size_t get_new_vl ();
size_t
__attribute__((noinline))
get_vl (size_t *c)
{
size_t vl = c[0] + c[1];
return vl;
}
vbool64_t
test_fail_2 (vuint64m1_t a, unsigned long b, size_t *c)
{
return __riscv_vmsne_vx_u64m1_b64 (a, b, get_vl (c));
}
---
test_fail_2:
[30/37834]
addisp,sp,-16
sd ra,8(sp)
sd s0,0(sp)
csrrt0,vlenb
sub sp,sp,t0
vs1r.v v1,0(sp)
sub sp,sp,t0
vs1r.v v2,0(sp)
sub sp,sp,t0
vs1r.v v3,0(sp)
sub sp,sp,t0
vs1r.v v4,0(sp)
sub sp,sp,t0
vs1r.v v5,0(sp)
sub sp,sp,t0
vs1r.v v6,0(sp)
sub sp,sp,t0
vs1r.v v7,0(sp)
sub sp,sp,t0
vs1r.v v24,0(sp)
sub sp,sp,t0
vs1r.v v25,0(sp)
sub sp,sp,t0
vs1r.v v26,0(sp)
sub sp,sp,t0
vs1r.v v27,0(sp)
sub sp,sp,t0
vs1r.v v28,0(sp)
sub sp,sp,t0
vs1r.v v29,0(sp)
sub sp,sp,t0
vs1r.v v30,0(sp)
sub sp,sp,t0
vs1r.v v31,0(sp)
csrrt0,vlenb
sub sp,sp,t0
vs1r.v v8,0(sp)
mv s0,a0
mv a0,a1
callget_vl
vl1re64.v v8,0(sp)
vsetvli zero,a0,e64,m1,ta,ma
vmsne.vxv0,v8,s0
csrrt0,vlenb
add sp,sp,t0
csrrt0,vlenb
vl1re64.v v31,0(sp)
add sp,sp,t0
vl1re64.v v30,0(sp)
add sp,sp,t0
vl1re64.v v29,0(sp)
add sp,sp,t0
vl1re64.v v28,0(sp)
...
As I understand, these callee saved vector registers are not required if the
function body doesn't pollute these registers. Only the polluted registers
need to go in/out stack.
However, it is somehow one optimization here, we can consider to improve this
in GCC-15 if my understanding is correct.
