https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92036
Bug ID: 92036
Summary: OpenACC 'firstprivate' clause: initial value
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openacc
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org
Target Milestone: ---
I think our implementation of OpenACC 'firstprivate' clause (on the OpenACC
'parallel' construct) is wrong regarding where such a variable gets initialized
from if a device copy already exists.
What we currently seem to be doing, in case that the respective original
variable already has a device copy, is to initialize the 'firstprivate' copy
from the *device* copy, which potentially might have a different value.
However, the OpenACC 2.0a specification in 2.5.10 "firstprivate clause" asks
that "the copy will be initialized with the value of that item *on the host*
when the 'parallel' construct is encountered" (emphasis mine), in other words
(my interpretation), initialized by the dynamic (current) value of the
*original* variable (specified in the 'firstprivate' clause) at the time the
OpenACC 'parallel' construct is encountered.
The current OpenACC 2.7 specification in 2.5.12. "firstprivate clause" asks
that "the copy will be initialized with the value of that item *on the local
thread* when a 'parallel' or 'serial' construct is encountered" (emphasis
mine). The term "local thread" in 6. "Glossary" gets defined as "the host
thread [...] that executes an OpenACC directive or construct" (omitted the
variant "or the accelerator thread" as that's (a) still the same semantics, and
(b) not relevant as long as we're not implementing OpenACC nested parallelism).
So, I read that as the same as the original OpenACC 2.0a.
This, per my current understanding, matches the semantics of the OpenMP
'firstprivate' clause. (Jakub?)
I suppose this needs to be re-worked (at least) in the gimplifier?
Not sure if that's related, but as far as I understand, the OpenACC handling of
'OMP_CLAUSE_FIRSTPRIVATE' in 'gcc/omp-low.c' is rather different from the
OpenMP handling -- might that also be relevant to this issue here?
