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?