[Bug middle-end/94876] New: [OpenACC] Unhelpful mapping for 'DECL_ARTIFICIAL' inside OpenACC 'kernels' regions

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94876

            Bug ID: 94876
           Summary: [OpenACC] Unhelpful mapping for 'DECL_ARTIFICIAL'
                    inside OpenACC 'kernels' regions
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: openacc
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
                CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48418&action=edit
'gcc/testsuite/c-c++-common/goacc/pr.c'

This is somewhat conceptually related to PR94874 "[OpenMP] Unhelpful
'defaultmap(none)' diagnostic for 'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not
specified in enclosing ‘target’'".

For OpenACC, we seem to be (totally/only?) relying on
'gcc/gimplify.c:oacc_default_clause' for determining how 'DECL_ARTIFICIAL'
objects are transported to the device.  In particular, for OpenACC 'kernels'
constructs, they inherit the behavior that "Scalars default to 'copy'" --
instead of the (supposedly) expected 'firstprivate'.  Even if not causing any
harm (now), that's definitely unfortunate/non-optimal.

See the 'gcc/testsuite/c-c++-common/goacc/pr.c' I'm attaching.


As mentioned in PR94874:

| I suppose for all such compiler-generated ('DECL_ARTIFICIAL') objects, we
shouldn't generate 'default(none)' diagnostics [we don't for OpenACC], but
instead make them available on the offloading device in the "best possible"
way.  (..., which probably defaults to 'firstprivate' given that these are
typically small-size objects?)  (Regarding the latter, see also
'gcc/gimplify.c:omp_shared_to_firstprivate_optimizable_decl_p', which applies
similar rationale regarding "large decls".)
|
| Also, for conceptual simplicity, I suppose any such compiler-generated
('DECL_ARTIFICIAL') objects should in some way be marked up with 'firstprivate'
clauses "explicitly by the compiler" when they are created, instead of having
['oacc_default_clause'] etc. do that.  (I have not studied that in detail.)  My
inclination would be to put an 'gcc_assert (!DECL_ARTIFICIAL(decl))' there? 
But maybe that's too hard.  Also need to sort out how that relates to
'lang_hooks.decls.omp_predetermined_sharing' etc.