[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687

2022-06-29 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED
   Target Milestone|--- |10.5

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed in gcc-10+, thus closing.

[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687

2022-01-18 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #4 from anlauf at gcc dot gnu.org ---
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.

[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687

2020-12-15 Thread anlauf at gcc dot gnu.org via Gcc-bugs
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.

[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687

2020-12-13 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-December/055420.html

[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687

2020-06-05 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-06-05
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
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 (>value.constructor,
   gfc_copy_expr (cons->expr), NULL);
 }