Affects versions down to at least r5, works without parameter : $ cat z1.f90 program p type t integer :: a = 1 end type type(t), parameter :: x(3) = t() type(t) :: y(1) y = [x(2:2)] print *, y end $ cat z2.f90 program p type t integer :: a = 1 end type type(t) :: x(3) = t() type(t) :: y(1) y = [x(2:2)] print *, y end $ gfortran-11-20200524 z2.f90 && ./a.out 1 $ $ gfortran-11-20200524 -c z1.f90 f951: internal compiler error: in find_array_section, at fortran/expr.c:1687 0x655de5 find_array_section ../../gcc/fortran/expr.c:1687 0x65735a simplify_const_ref ../../gcc/fortran/expr.c:1892 0x657ebe gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2278 0x6580c3 simplify_parameter_variable ../../gcc/fortran/expr.c:2107 0x657e8d gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2245 0x6208fd expand_constructor ../../gcc/fortran/array.c:1814 0x622c77 gfc_array_size(gfc_expr*, __mpz_struct (*) [1]) ../../gcc/fortran/array.c:2648 0x6bbfbf expression_shape ../../gcc/fortran/resolve.c:5390 0x6bbfbf gfc_expression_rank(gfc_expr*) ../../gcc/fortran/resolve.c:5464 0x6bd8bf gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7076 0x6c6144 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:11653 0x6c6144 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11746 0x6c7747 resolve_codes ../../gcc/fortran/resolve.c:17257 0x6c780e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17292 0x6af99c resolve_all_program_units ../../gcc/fortran/parse.c:6245 0x6af99c gfc_parse_file() ../../gcc/fortran/parse.c:6492 0x6fb9af gfc_be_parse_file ../../gcc/fortran/f95-lang.c:210
This allows the code to compile and print 1. Index: gcc/fortran/expr.c =================================================================== --- gcc/fortran/expr.c (revision 280157) +++ gcc/fortran/expr.c (working copy) @@ -1684,7 +1684,13 @@ find_array_section (gfc_expr *expr, gfc_ref *ref) } cons = gfc_constructor_lookup (base, limit); - gcc_assert (cons); + + if (!cons) + { + t = false; + goto cleanup; + } + gfc_constructor_append_expr (&expr->value.constructor, gfc_copy_expr (cons->expr), NULL); }
Patch: https://gcc.gnu.org/pipermail/fortran/2020-December/055420.html
Playing around with the above patches, I found that the following now gets rejected instead of an ICE: program p type t integer :: a = 1 end type t type(t), parameter :: z(3) = t() type(t) :: v(1) = z(2:2) ! Rejected ! type(t) :: v(1) = [z(2:2)] ! Rejected print *, v% a end pr95372-1.f90:6:3: 6 | type(t) :: v(1) = z(2:2) ! Rejected | 1 Error: Unclassifiable statement at (1) pr95372-1.f90:8:14: 8 | print *, v% a | 1 Error: Symbol 'v' at (1) has no IMPLICIT type This is a consequence of find_array_section returning false instead of true. However, removing the t=false from the patch the original testcase will ICE in a different place. Staring some more at the code in find_array_section, it appears that there is a stale cons = gfc_constructor_first (base); followed later by the critical cons = gfc_constructor_lookup (base, limit); Strange. And "git blame" so far did not really help me much.
Seems to work at r12-6697, r11-9477 and r10-10403. gcc-9 still fails. Does a bisection make sense to find what fixed it? Otherwise we could close it and set the target milestone to 10.4.
Fixed in gcc-10+, thus closing.