[Bug middle-end/94874] New: [OpenMP] Unhelpful 'defaultmap(none)' diagnostic for 'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not specified in enclosing ‘target’'

[tschwinge at gcc dot gnu.org]

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

            Bug ID: 94874
           Summary: [OpenMP] Unhelpful 'defaultmap(none)' diagnostic for
                    'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not specified
                    in enclosing ‘target’'
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: openmp
          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 48417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48417&action=edit
'gcc/testsuite/c-c++-common/gomp/pr.c'

[...]/pr.c:24:37: error: ‘array_li.0’ not specified in enclosing ‘target’
       24 |     array_so_openmp_target = sizeof array;
          |                              ~~~~~~~^~~~~

I suppose for all such compiler-generated ('DECL_ARTIFICIAL') objects, we
shouldn't generate 'default(none)'/'defaultmap(none)' diagnostics, 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
'omp_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.


Back to the diagnostic here, for '-x c++' we get, worse:

    [...]/pr.c:24:28: error: ‘’ not specified in enclosing ‘target’
       24 |     array_so_openmp_target = sizeof array;
          |     ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~

(Notice the empty '‘’'.)  Per GDB:

    Breakpoint 1, omp_notice_variable (ctx=0x2d2fc10,
decl=decl@entry=0x7ffff7feee10, in_code=in_code@entry=true) at
[...]/source-gcc/gcc/gimplify.c:7487
    7487                          error ("%qE not specified in enclosing
%<target%>",
    (gdb) print d
    $1 = (tree) 0x7ffff7feee10
    (gdb) call debug_tree(d)
     <var_decl 0x7ffff7feee10 D.2560
        type <integer_type 0x7ffff67c3150 ssizetype public DI
            size <integer_cst 0x7ffff67a5e70 constant 64>
            unit-size <integer_cst 0x7ffff67a5e88 constant 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff67c3150 precision:64 min <integer_cst 0x7ffff67a5000
-9223372036854775808> max <integer_cst 0x7ffff67a5f00 9223372036854775807>>
        used ignored DI [...]/pr.c:8:23 size <integer_cst 0x7ffff67a5e70 64>
unit-size <integer_cst 0x7ffff67a5e88 8>
        align:64 warn_if_not_align:0 context <function_decl 0x7ffff6933d00
vla>>
    (gdb) print d.decl_minimal.name
    $2 = (tree) 0x0

Doing something like 'gcc/fortran/trans-openmp.c:gfc_omp_report_decl' doesn't
easily help here, because:

    (gdb) print d.decl_common.artificial_flag
    $3 = 1
    (gdb) print d.decl_common.lang_specific
    $4 = (lang_decl *) 0x0