[Patch][RFC] openmp: don't add aritificial const decl to offload table (PRs 94848 + 95551)

[Tobias Burnus]

In the latest PR95551, the issue came up with a Fortran array
constructor ("if ((any (array /= [(-i, i=1, 10)])") used
in a target section within a host procedure. The constructor
is converted into a static local variable
   A.10 = [-1, -2, ...]
ends up in omp-offload.c's offload_vars.

With -O3 optimization, the variable is optimized away on the
host side but it is still in the .gnu.offload_vars (→ host_table,
target_data), causing link errors.

  * * *

I think there is a wider issue (→PR 95551 and others) regarding the
consistency between host and target variables and optimizations, but
I wonder why such a variables has to appear at all in the offload_vars
table.

Hence, I am thinking of the attached patch which does not add TREE_READONLY
variables to .gnu.offload_vars; I additionally require TREE_ARTIFICIAL as I
am thinking of the case such as Fortran parameter to which one an create a
pointer to – which might require the mapping information (is_device_{addr,ptr}).
[The question is whether more needs to be excluded, e.g. to exclude
virtual tables from the exlusion? For instance by requiring
   TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL ?]

For the test case, with -O3, the variable (A.10.3) is optimized away and
seemingly also not streamed out as it also does not appear with -foffload="-O0".

Thoughts?

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-offload-skip-v2.diff
Type: text/x-patch
Size: 3508 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200608/85ccd1d1/attachment-0001.bin>