https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90067
Bug ID: 90067
Summary: Loop variables in Fortran 'do' statements within a
compute construct must be predetermined private
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: openacc
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
Target Milestone: ---
Found while working on PR90048.
OpenACC 2.6 (same in 2.7), in section 2.6.1. "Variables with Predetermined Data
Attributes" states that "The loop variable in a C 'for' statement or Fortran
'do' statement that is associated with a loop directive is predetermined to be
private to each thread that will execute each iteration of the loop. Loop
variables in Fortran 'do' statements within a compute construct are
predetermined to be private to the thread that executes the loop".
Regarding the latter, for Fortran 'do' statements that are not directly
associated with a 'loop' directive, when these 'do' statements are (somewhere)
nested inside a 'loop' construct, we implement this in the front end by adding
a 'private' clause to the containing 'loop' construct, but when these 'do'
statements are not (somewhere) nested inside a 'loop' construct, we do not add
a 'private' clause to the containing compute construct. For example, for:
integer :: i
!$acc parallel
do i = 1, 100
end do
!$acc end parallel
..., we do not in the front end add a 'private(i)' clause to the 'parallel'
construct.
By the rules as presented in section 2.5. "Compute Constructs", the gimplifier
will then fix this up by adding a 'firstprivate' clause, in the common case of
the 'parallel' construct (same for the 'serial' construct, but a 'copy' clause
for the 'kernels' construct!).
While it might generally be beneficial to have a pass promoting
'firstprivate(x)' with a dominating write operation on 'x' to 'private(x)',
here it would be better (and much simpler) to handle this in the front end.
