https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80330
Bug ID: 80330
Summary: OpenACC: Unexpected data mapping instead of implicit
firstprivate
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: openacc
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: cesar at gcc dot gnu.org
Target Milestone: ---
Created attachment 41136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41136&action=edit
implicit-firstprivate-1.f90
Compile the attached "implicit-firstprivate-1.f90" (lifted from
"libgomp.oacc-fortran/pr70643.f90") with "-fdump-tree-gimple", and observe
that:
!$acc data
!$acc parallel loop
do k=y_min,y_max
!$acc loop
do j=x_min,x_max
... gets translated into:
#pragma omp target oacc_data
{
try
{
{
integer(kind=4) D.3517;
integer(kind=4) D.3518;
D.3517 = y_min;
D.3518 = y_max;
#pragma omp target oacc_parallel map(tofrom:D.3518 [len: 4])
map(tofrom:D.3517 [len: 4]) firstprivate(x_min) firstprivate(x_max)
In particular, notice "firstprivate(x_min) firstprivate(x_max)" as expected,
but why are "y_min" and "y_max" put into temporaries first, and then
transmitted via "tofrom" mappings?
I have not yet spent enough time to construct a test case where this causes a
correctness problem, but it seems wrong as-is.
This only seems to happen for a combined "parallel loop" construct, and only if
there is an outer "data" construct.
In fact, it's the code in "gcc/gimplify.c" ,"omp_notice_variable", below "Look
in outer OpenACC contexts, to see if there's a data attribute for this
variable", that is then setting "GOVD_MAP", which translates to "tofrom". (I
stumbled over this issue when changing said code to set "force_present" instead
of "tofrom"; "libgomp.oacc-fortran/pr70643.f90" was the only testsuite
regression.)
Said OpenACC-specific code looks similar to what is being done for OpenMP in
"omp_default_clause", but it's not the same. In particular, for OpenACC, we
don't consider (as many cases of?) "omp_predetermined_sharing (decl)" (some of
them seem to be implemented in an ad-hoc way?) -- but I don't know if that or
something else in the gimplifier is actually the problem, or if it is something
in the Fortran front end?
