On Thu, 16 Jul 2020 15:53:54 +0200 Tobias Burnus <tob...@codesourcery.com> wrote:
> [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? I don't know when we'd have TREE_READONLY and DECL_EXTERNAL in a situation where it made sense to mark the decl private using this mechanism -- but I'll defer to your judgement! > Additional comments? > Does it look OK for OG10? Looks OK to me, FWIW. Thanks, Julian
