https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372
--- Comment #3 from anlauf at gcc dot gnu.org --- 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.