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
(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...
The dump-fortran-original shows the following difference between 13 and 14: @@ -58,7 +58,7 @@ code: ASSIGN p:c 'abc' - BLOCK + SELECT TYPE symtree: '__tmp_CHARACTER_0_1'|| symbol: '__tmp_CHARACTER_0_1' type spec : (CHARACTER () 1) attributes: (VARIABLE SELECT-TYPE-TEMPORARY ASSOCIATE-VAR) @@ -66,7 +66,7 @@ type spec : (UNKNOWN 0) attributes: (LABEL ) - SELECT TYPE _loc[((p:c % _vptr))] + SELECT CASE _loc[((p:c % _vptr))] CASE (_loc[((p:__vtab_CHARACTER_1_))] 85893463) ASSOCIATE = p:c % _data @@ -74,11 +74,11 @@ type spec : (UNKNOWN 0) attributes: (LABEL ) WRITE UNIT=6 FMT=-1 - TRANSFER block@1:__tmp_CHARACTER_0_1(2:2) + TRANSFER block@1:__tmp_CHARACTER_0_1(UNKNOWN) DT_END END ASSOCIATE END SELECT - END BLOCK + END SELECT TYPE CONTAINS
Adding Paul, hoping that he can tell what changed for SELECT TYPE recently.
(In reply to anlauf from comment #3) > Adding Paul, hoping that he can tell what changed for SELECT TYPE recently. Hmmm! Nothing that I am aware of. I'll take a look tomorrow, The changes are most strange. Why do I get that horrible feeling? Paul
(In reply to Paul Thomas from comment #4) > (In reply to anlauf from comment #3) > > Adding Paul, hoping that he can tell what changed for SELECT TYPE recently. > When c is an array, it compiles and runs fine with mainline. The parse-tree looks sensible too, unlike the scalar version. program p implicit none class(*), allocatable :: c(:) c = ['abc'] select type (c) type is (character(*)) print *, c print *, c(1)(2:2) ! Doesn't ICE end select end Paul
(In reply to anlauf from comment #3) > Adding Paul, hoping that he can tell what changed for SELECT TYPE recently. Needless to say, the regression is caused by r14-9489. I have a fix that regtests OK but causes a regression in an, as yet, untested corner: subroutine foobar type :: t integer :: i end type class(*), allocatable :: c c = t (1) select type (c) type is (t) if (c(1)%i .ne. 1) stop 5 ! This now ICEs end select end My efforts have been interrupted by a failure of make-install, which seems to happen every few months. I rather think that I should go back to magnetic drives, rather than SSD. It will now have to wait until tomorrow. Paul
Created attachment 58104 [details] Fix for this PR This seems to be the best fix. I have tried several different approaches in the last two days but it has been an uphill struggle against the state of the block namespaces at this stage of the compilation. I'll think about it for another day or so before submitting. Cheers Paul
GCC 14.1 is being released, retargeting bugs to GCC 14.2.
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>: https://gcc.gnu.org/g:5f5074fe7aaf9524defb265299a985eecba7f914 commit r15-633-g5f5074fe7aaf9524defb265299a985eecba7f914 Author: Paul Thomas <pault@gcc.gnu.org> Date: Fri May 17 15:19:26 2024 +0100 Fortran: Fix select type regression due to r14-9489 [PR114874] 2024-05-17 Paul Thomas <pault@gcc.gnu.org> gcc/fortran PR fortran/114874 * gfortran.h: Add 'assoc_name_inferred' to gfc_namespace. * match.cc (gfc_match_select_type): Set 'assoc_name_inferred' in select type namespace if the selector has inferred type. * primary.cc (gfc_match_varspec): If a select type temporary is apparently scalar and a left parenthesis has been detected, check the current namespace has 'assoc_name_inferred' set. If so, set inferred_type. * resolve.cc (resolve_variable): If the namespace of a select type temporary is marked with 'assoc_name_inferred' call gfc_fixup_inferred_type_refs to ensure references are OK. (gfc_fixup_inferred_type_refs): Catch invalid array refs.. gcc/testsuite/ PR fortran/114874 * gfortran.dg/pr114874_1.f90: New test for valid code. * gfortran.dg/pr114874_2.f90: New test for invalid code.
The releases/gcc-14 branch has been updated by Paul Thomas <pault@gcc.gnu.org>: https://gcc.gnu.org/g:c887341432bb71cf5540d54955ad7265b0aaca77 commit r14-10216-gc887341432bb71cf5540d54955ad7265b0aaca77 Author: Paul Thomas <pault@gcc.gnu.org> Date: Fri May 17 15:19:26 2024 +0100 Fortran: Fix select type regression due to r14-9489 [PR114874] 2024-05-17 Paul Thomas <pault@gcc.gnu.org> gcc/fortran PR fortran/114874 * gfortran.h: Add 'assoc_name_inferred' to gfc_namespace. * match.cc (gfc_match_select_type): Set 'assoc_name_inferred' in select type namespace if the selector has inferred type. * primary.cc (gfc_match_varspec): If a select type temporary is apparently scalar and a left parenthesis has been detected, check the current namespace has 'assoc_name_inferred' set. If so, set inferred_type. * resolve.cc (resolve_variable): If the namespace of a select type temporary is marked with 'assoc_name_inferred' call gfc_fixup_inferred_type_refs to ensure references are OK. (gfc_fixup_inferred_type_refs): Catch invalid array refs.. gcc/testsuite/ PR fortran/114874 * gfortran.dg/pr114874_1.f90: New test for valid code. * gfortran.dg/pr114874_2.f90: New test for invalid code. (cherry picked from commit 5f5074fe7aaf9524defb265299a985eecba7f914)
Hi Harald, Your comments have been implemented and the patch committed to both affected branches. Thanks for the report and your help in honing up the fix. Paul
*** Bug 115193 has been marked as a duplicate of this bug. ***