[Bug fortran/92790] New: [OpenACC] declare device_resident - Fortran common blocks not handled / libgomp.oacc-fortran/declare-5.f90 fails

[burnus at gcc dot gnu.org]

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

            Bug ID: 92790
           Summary: [OpenACC] declare device_resident - Fortran common
                    blocks not handled /
                    libgomp.oacc-fortran/declare-5.f90 fails
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: openacc
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: tschwinge at gcc dot gnu.org
        Depends on: 63859, 90921, 92728
  Target Milestone: ---

Related:
PR 90921 - this introduced the questionable module code, mentioned below;
           it looks like a work-around for the issue of the main point in
           this PR.
PR 63859 (a bit unclear what this PR is about)
(PR 92728 – ordering of common-block decl and using it in a decl+blank commons)


It turned out that for Fortran's common blocks, OpenACC's 'declare
device_resident' is not handled – causing libgomp.oacc-fortran/declare-5.f90 to
fail.

There is a RFC patch for this at the end of 
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00149.html


However, the patch causes that the same(-)named common block is marked as
'declare target' in multiple procedures. That seems to be very sensible from
the FE side. However, the ME code generates multiple times the same mapping
code. Result:

libgomp: Trying to map into device [0x407218..0x40721c) object when
[0x407210..0x40721c) is already mapped

Ideally, the ME part would consolidate all of them into a single item (at least
per translation unit). And to support multiple translation units, the libgomp
part should be handles as 'pcreate' not as with 'create'.
[In terms of common blocks, those are static variables with the same name,
pointing to the same memory block.]


Additional issues (cf. email):

* Code for handling modules variables looks fragile (seems to assume that the
module symbol ends up in the main program) - that code looks like a work-around
for the issue above. 

* Unclear what exactly get's mapped for
    integer :: a,b,c
    common /name/ a, b, c
    declare device_resident(a)
  will this map the whole /name/?  (Current patch does so, cf. email;
  other variants will also ICE)

  I think it only makes sense if OpenACC requires that all is mapped, e.g.
  by requiring the explicit /name/ instead of permitting single common-block
  variables. Otherwise, it could also be handled by the FE as currently done,
  i.e. if one of them is device-resident, all are.

* General question what's meant by device resident, i.e., whether the
  same-named common block also exists on the host, i.e.
    copy(/name/)
  will map all of the host's common block to the device and back.
  Of whether they only exist on the device, such that one passes individual
  variables, which happen to have the same name, i.e.
    copy(/name/)
  passes a, b, c and one has to take care of them as single variables in the
  parallel/kernels block.

* Question whether OpenACC permits:
  block data
    ...
    common /name/
  end block data

* Blank commons spec issue, PR 92728

* Data mapping question - i.e. if /name/ is device resident; will automatic
mapping imply copy() and firstprivate for common-block variables accessed in
the parallels/kernels block?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63859
[Bug 63859] Fortran OpenACC declare directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90921
[Bug 90921] Fortran OpenACC 'declare' directive's module handling causes
duplicate data clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92728
[Bug 92728] [OpenMP][OpenACC] Common-block name clause matching issues: common
block needs to be defined before + blank common not supported