[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 via Gcc-bugs]

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

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

https://gcc.gnu.org/g:55c86c6cb2ef2a028a33b1dcaa39169355caba1a

commit r16-7647-g55c86c6cb2ef2a028a33b1dcaa39169355caba1a
Author: Paul-Antoine Arras <par...@baylibre.com>
Date:   Fri Feb 20 14:21:55 2026 +0100

    OpenMP/Fortran: Enforce component order when mapping allocatable DT
[PR120505]

    This is a follow-up to r16-5789-g05c2ad4a2e7104.

    Consider the following code, assuming tiles is allocatable:

    type t
     integer, allocatable :: den1(:,:), den2(:,:)
    end type t
    [...]
    !$omp target enter data map(var%tiles(1)%den2, var%tiles(1)%den1)

    r16-5789-g05c2ad4a2e7104 allowed mapping several components from the same
    allocatable derived type, provided they are in the right order in user
code.
    This patch relaxes this constraint by computing offsets and sorting
to-be-mapped
    components at gimplification time.

            PR fortran/120505

    gcc/ChangeLog:

            * gimplify.cc (omp_accumulate_sibling_list): When the containing
struct
            is a Fortran array descriptor, sort mapped components by offset.

    libgomp/ChangeLog:

            * testsuite/libgomp.fortran/map-subarray-12.f90: New test.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/gomp/map-subarray-4.f90: New test.