[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989

2021-05-01 Thread anlauf at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206

--- Comment #6 from anlauf at gcc dot gnu.org ---
I agree that there is a strange bookkeeping issue.

Swapping the order of the two functions in comment#0 makes the ICE go away.

Printing forall_save, nvar, total_var in gfc_resolve_forall may give a clue
what makes the difference.

[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989

2021-04-30 Thread kargl at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #4)
> Still present in v12.0.

First, I recognize that the submitted code is likely a severely reduced
testcase to demonstrate the bug.

Because FORALL is now listed as an obsolescent feature, I predict that this bug
will never be fixed unless someone who is keenly interested in FORALL steps up.

The issue is in resolve.c(gfc_resolve_forall) where static variables are used
to track nested FORALL statements.  The nesting is assumed to be of the form:

   pure function zero_matrix(xx) result(ret)
 real , intent(in) :: xx(:,:)
 real :: ret(size(xx,1),size(xx,2))
 integer :: i,j
 forall (i=1:size(xx,1),j=1:size(xx,2)) ret(i,j) = 0
   end function zero_matrix

or maybe

   pure function zeroing(xx) result(ret)
  real , intent(in) :: xx(:,:)
  real :: ret(size(xx,1),size(xx,2))
  integer :: i,j
  a: forall (j=1:size(xx,2))
 b: forall (i=1:size(xx,1))
ret(i,j) = 0
 end forall b
  end forall a
   end function zeroing

Here, the I and J variables are tracked, where gfc_resolve_forall()
is called recursively.

I'm guessing that the single line nature of your zero_mat() function
does not properly reset the static variables.  This would look like

 a: forall (j=1:size(xx,2))
 b: forall (i=1:size(xx,1))
ret(i,j) = 0
 end forall a
 or

 a: forall (j=1:size(xx,2))
 b: forall (i=1:size(xx,1))
ret(i,j) = 0
 end forall b

with a missing closing END FORALL.  gfortran, of course, catches the
missing END FORALL because it is not parsing in the single-line FORALL
mode.

[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989

2021-04-30 Thread juergen.reuter at desy dot de via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206

--- Comment #4 from Jürgen Reuter  ---
Still present in v12.0.

[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989

2018-06-22 Thread anlauf at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206

--- Comment #3 from Harald Anlauf  ---
No ICE if the module is split into two parts:

! No ICE
module zero_mod
  implicit none
contains
  pure function zero_vec(xx) result(ret)
real, intent(in) :: xx(:)
real :: ret(size(xx))
integer :: i
forall (i=1:size(xx)) ret(i) = 0.0
  end function zero_vec
end module zero_mod

module zero_mod2
  use zero_mod
  implicit none
contains
  pure function zero_mat(xx) result(ret)
real, intent(in) :: xx(:,:)
real :: ret(size(xx,1),size(xx,2))
integer :: j
forall (j=1:size(xx,2)) ret(:,j) = zero_vec(xx(:,j))
  end function zero_mat
end module

[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989

2018-06-19 Thread anlauf at gmx dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
4.8 and 4.9 work, thus 5 regression.

[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989

2018-06-19 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-06-19
Summary|ICE in forall   |ICE in gfc_resolve_forall,
   ||at fortran/resolve.c:9989
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.