[Patch][OG10] omp-low.c: Avoid offload-target lto1 is-missing error by not-privatizing TREE_READONLY vars

Tobias Burnus tobias@codesourcery.com
Thu Jul 16 13:53:54 GMT 2020


[This is an OpenACC issue but I would not completely surprised if
something similar could occur for OpenMP offloading as well.
However, the patch is for an OpenACC-specific function.]

This issue occurs for libgomp.oacc-fortran/privatized-ref-2.f90, for which
on the device lto1 complains:
lto1: fatal error: /tmp/ccEGJTZN.o: section A.13.1.21 is missing Here,
"A.13" is a TREE_STATIC, TREE_READONLY array generated by the Fortran
front-end and containing the array-constructor values, i.e. RHS of:
array = [(-2*i, i = 1, size(array))] That testcase works on the trunk or
on the OG10 (= devel/omp/gcc-10) branch if one reverts the patch "Re-do
OpenACC private variable resolution"
https://gcc.gnu.org/g:2f4b477223fddb84f66e494eb88d1defbd5e04a2 which is
scheduled but not yet submitted for mainline inclusion. The offloading
variable table contains the variable as "A.13.10" (which works fine) and
the problem-causing patch causes that the code   .UNIQUE (OACC_PRIVATE, 0, 0, &parm.9, &A.13);
gets inserted (via the then-added make_oacc_private_marker in omp-low.c).
Here, the decl for 'A.13' does not have a varpool_node entry – and
it is not streamed out as separate entity.
(This IFN_ is then later processed by the target lto1 via omp-offload.c's
execute_oacc_device_lower – where the asm_name "A.13.1" appears.)

[While I do not completely understand why the target LTO does
not contain the symbol, I think the following still makes sense.
(I do understand why the offload var table does not contain it.)]


If the variable is TREE_READONLY, there is no need to pass it
through the variable-privatization bits.

The current check is for VAR_P and TREE_ADDRESSABLE. For the fix,
one could use:
   !TREE_READONLY
or
   !(TREE_READONLY && TREE_STATIC)
or
   !(TREE_READONLY && (TREE_STATIC || DECL_EXTERNAL)
I am not sure what makes more sense. I initially used the first
version and then moved to the last. Thoughts?

Additional comments?
Does it look OK for OG10?

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: priv.diff
Type: text/x-patch
Size: 1151 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200716/7f0e763a/attachment.bin>


More information about the Gcc-patches mailing list