https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120505
Bug ID: 120505
Summary: [OpenMP] Fortran deep mapping of alloc comp +
component mapping like 'map(var%arr(1)%alloc)' in
target (enter/exit) data
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Created attachment 61559
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61559&action=edit
Fortran testcase
Found with SPEC hpc's 619.clvleaf_s. The problem is code like:
-----------------
!$omp target enter data map(var%tiles(1)%den1, var%tiles(1)%den2)
...
!$omp target map(var) ! explicit or implicit.
-----------------
The latter attempts a deep mapping of 'var' – which will have issues if part of
the data has already been mapped:
- extending partially mapped data
- mapping "too much".
RFC: What does 'target enter data map(var%tiles(1)%den1, ...%den2)' map?
Just a (partial) struct map of 'type t', i.e.
struct var.tiles->data(1) [len: 2]
map var.tiles->data(1).den1 (+ alloc comp)
map var.tiles->data(1).den2 (+ alloc comp)
or because it is an allocatable component (C++ reference type), does it also
map:
struct var [len: 1]
var.tiles (+ attach of...)
var.tiles->data
+ attach var.tiles->data(1) to data
In any case,
'!$omp target map(/* always : */ var)'
shall not map 'var%tiles(1)%den3' (as 'den{1,2}' has been struct mapped) -
attempting to do so will cause an runtime error.
Still, with 'map(always: var)'
* 'var%tiles(1)%den{1,2}' has to be updated
* if either of them was previous unallocated, they should get deep mapped.
If 'var' counts as mapped (see RFC above), there is no need to walk the
allocatable components, except for 'always'.
In particular, the previously unmapped 'var%tiles(2)' shouldn't be mapped in
that case - as 'var%tiles(1)' has then be mapped before.
* * *
Possible ingredients to solve this issue:
* GCC could add 'implicit' to the deep mapping (might not be needed)
* add 'begin/end alloc comp' flags to 'kinds'
- need to check whether where - and whether that solves the skip
'dep3->data' mapping and + dep3 map/attach, but still handles
updating dep{1,2}->data updating (with always) deep mapping of
either (if previously unallocated + 'always').
