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