[Bug fortran/120505] [OpenMP] Fortran deep mapping of alloc comp + component mapping like 'map(var%arr(1)%alloc)' in target (enter/exit) data

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul-Antoine Arras <parras@gcc.gnu.org>:

https://gcc.gnu.org/g:05c2ad4a2e710494887bcfc334c978c04a6f7994

commit r16-5789-g05c2ad4a2e710494887bcfc334c978c04a6f7994
Author: Paul-Antoine Arras <parras@baylibre.com>
Date:   Fri Nov 28 15:40:44 2025 +0100

    OpenMP/Fortran: Allow explicit map followed by implicit deep mapping
[PR120505]

    Consider the following source code, assuming tiles is allocatable:

    ```
    !$omp target enter data map(var%tiles(1)%den1, var%tiles(1)%den2) !       
(1)
    [...]
    !$omp target ! implicitly maps var, which triggers deep mapping of tiles  
(2)
    ```

    Each omp directive causes a run-time error in libgomp:
    (1) libgomp: Mapped array elements must be the same (0x14d729c0 vs
0x14d72a18)
    (2) libgomp: Trying to map into device [0x3704ca50..0x3704cb00) object when
                 [0x3704ca50..0x3704caa8) is already mapped

    Regarding (1), the OpenMP spec has the following restriction: "If multiple
list
    items are explicitly mapped on the same construct and have the same
containing
    array or have base pointers that share original storage, and if any of the
list
    items do not have corresponding list items that are present in the device
data
    environment prior to a task encountering the construct, then the list items
must
    refer to *the same array elements* of either the containing array or the
    implicit array of the base pointers."
    Because tiles is allocatable, we cannot prove at compile time that array
    elements are the same, so the check is deferred to libgomp. But there the
    condition enforcing that all addresses are the same is too strict, so this
patch
    relaxes it to only check that addresses are sorted in increasing order.

    The OpenMP spec allows (2) as long as it is implicit, without extending the
    original mapping. So this patch sets the GOMP_MAP_IMPLICIT flag
appropriately
    on deep maps at compile time to let libgomp know that it is fine.

    This patch ensures that such user code is accepted by:
    (1) Setting the GOMP_MAP_IMPLICIT flag appropriately on deep maps;
    (2) Relaxing the restriction on struct mapping from different containing
arrays,
    so that the element index need not be the same, instead addresses must be
sorted
    in increasing order.

    This fixes the two errors currently seen when running SPEC HPC clvleaf
    benchmark. However, further mapping issues prevent the benchmark from
running to
    completion.

            PR fortran/120505

    gcc/ChangeLog:

            * omp-low.cc (lower_omp_target): Set GOMP_MAP_IMPLICIT flag.

    libgomp/ChangeLog:

            * target.c (gomp_map_vars_internal): Allow struct mapping from
different
            containing array elements as long as adresses are in increasing
order.
            * testsuite/libgomp.c-c++-common/map-arrayofstruct-2.c: Adjust
            dg-output.
            * testsuite/libgomp.c-c++-common/map-arrayofstruct-3.c: Likewise.
            * testsuite/libgomp.fortran/map-subarray-5.f90: Likewise.
            * testsuite/libgomp.fortran/map-subarray-10.f90: New test.
            * testsuite/libgomp.fortran/map-subarray-9.f90: New test.