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

[Jakub Jelinek]

On Fri, May 08, 2020 at 05:09:07PM +0200, Tobias Burnus wrote:
> 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:

I think we want a new hook, the clear cases (mostly DECL_ARTIFICIAL ones,
if it is really something compiler created and not something under user's
control) handle the way we find best for them (perhaps firstprivate
in some cases, though e.g. for typeinfo and vtables I think we want to make
them declare target to), but for user-visible stuff best file a github
OpenMP/spec issue (can you please do that) and discuss there?
I mean, if something is predetermined firstprivate, then one could in some
reading assume it then can't be specified and must be firstprivatized on
target (or as an exception may be specified but still default to being
firstprivatized), but if the spec says that e.g. static data members are
predetermined shared, then I don't see how that makes any difference to
how it should be mapped or not.  So, it is unclear what
void bar (const char *);
#pragma omp declare target to (bar)
void foo ()
{
  #pragma omp target defaultmap(none)
  bar (__FUNCTION__);
}
should be doing, etc.; target really doesn't have shared clauses and nothing
says that variables that have predetermined data sharing of shared are say
mapped(tofrom:) implicitly.

	Jakub