[Patch][OpenMP] Fix mapping of artificial variables (PR94874)

[Tobias Burnus]

While for data sharing (e.g. "parallel") the
predetermined sharing (e.g.) for compiler-generated
variables did work, this did not happen for target
mapping – causing errors with "defaultmap(none)".

It is not completely clear to my how to best handle
this case. In most cases, the auxiliary variable is
scalar and never modified – currently, they become
"map(tofrom:)" which looks like a missed optimization.

I was thinking of simply marking them as
"nflags |= GOVD_FIRSTPRIVATE" but I am not sure whether
that would always make sense, either. In any case, a
simple usage would bypass the
"implicit mapping of assumed size array"
diagnostic in gfc_omp_finish_clause.

One could also use a value returned by the hook,
but currently it is tailored for shared memory
use only. A fix would be either a new argument
("bool for_mapping") plus special handling or
a new hook. In any case, the current hook has:

For C and most cases of C++:
   OMP_CLAUSE_DEFAULT_SHARED
except that C++ return for current_class_ptr:
   OMP_CLAUSE_DEFAULT_FIRSTPRIVATE

But Fortran is very complex. A simple handling
is also not possible as some things (like
a C++/Fortran class pointer or probably
Cray pointer) need pointer mapping.
[C++: RTTI/dynamic_cast permitted; Fortran:
RTTI + virtual calls permitted.]

Hence, I went for the simple solution.

OK for the trunk? If is, is it worthwhile to
backport to the GCC 10 branch?


Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omp-target-defltmap-v2.diff
Type: text/x-patch
Size: 2363 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200508/8cdebb97/attachment.bin>