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.
