[Bug fortran/80330] New: OpenACC: Unexpected data mapping instead of implicit firstprivate

[tschwinge at gcc dot gnu.org]

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?