Bug 95372 - ICE in find_array_section, at fortran/expr.c:1687
Summary: ICE in find_array_section, at fortran/expr.c:1687
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 11.0
: P4 normal
Target Milestone: 10.5
Assignee: anlauf
Keywords: ice-on-valid-code
Depends on:
Reported: 2020-05-27 18:59 UTC by G. Steinmetz
Modified: 2022-06-29 18:09 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2020-06-05 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description G. Steinmetz 2020-05-27 18:59:37 UTC
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

$ 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

$ gfortran-11-20200524 z2.f90 && ./a.out
$ gfortran-11-20200524 -c z1.f90
f951: internal compiler error: in find_array_section, at fortran/expr.c:1687
0x655de5 find_array_section
0x65735a simplify_const_ref
0x657ebe gfc_simplify_expr(gfc_expr*, int)
0x6580c3 simplify_parameter_variable
0x657e8d gfc_simplify_expr(gfc_expr*, int)
0x6208fd expand_constructor
0x622c77 gfc_array_size(gfc_expr*, __mpz_struct (*) [1])
0x6bbfbf expression_shape
0x6bbfbf gfc_expression_rank(gfc_expr*)
0x6bd8bf gfc_resolve_expr(gfc_expr*)
0x6c6144 gfc_resolve_expr(gfc_expr*)
0x6c6144 gfc_resolve_code(gfc_code*, gfc_namespace*)
0x6c7747 resolve_codes
0x6c780e gfc_resolve(gfc_namespace*)
0x6af99c resolve_all_program_units
0x6af99c gfc_parse_file()
0x6fb9af gfc_be_parse_file
Comment 1 kargl 2020-06-05 16:18:00 UTC
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);
Comment 3 anlauf 2020-12-15 19:31:39 UTC
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


    6 |   type(t)            :: v(1) =  z(2:2)  ! Rejected
      |   1
Error: Unclassifiable statement at (1)

    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.
Comment 4 anlauf 2022-01-18 20:19:51 UTC
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.
Comment 5 anlauf 2022-06-29 18:09:02 UTC
Fixed in gcc-10+, thus closing.