[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 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 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 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
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 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 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 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 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 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 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 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 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 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] 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 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 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 #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] 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 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++/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 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 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=edit Patch part 2. This part fixes the array case. Needs further testing.
[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 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 #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 #1 from Antonio Rojas --- Created attachment 58055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58055=edit output of gcc -save-temps
[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] 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/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 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 --- 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/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/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=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 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 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.
