[Bug middle-end/110270] New: [OpenMP] OpenMP 5.2 – firstprivate of pointer shall retain the value if pointee is not mapped

[Bug middle-end/110270] New: [OpenMP] OpenMP 5.2 – firstprivate of pointer shall retain the value if pointee is not mapped

[burnus at gcc dot gnu.org]

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

            Bug ID: 110270
           Summary: [OpenMP] OpenMP 5.2 – firstprivate of pointer shall
                    retain the value if pointee is not mapped
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: openmp, wrong-code
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55328
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55328&action=edit
C/C++ testcase

Testcase → See attachment — another one would be
libgomp.c-c++-common/requires-unified-addr-1.c with the 'defaultmap's removed
or changed to  either 'defaultmap(default)' or 'defaultmap(default:pointer)'.

 * * *

The following quote is from a section that is marked as "C / C++" only.

OpenMP 5.2's "5.8.6 Pointer Initialization for Device Data Environments" (last
paragraph) has:

"If a matching mapped list item is not found, the pointer retains its original
value as per the firstprivate semantics described in Section 5.4.4."


OpenMP 5.1's 2.21.7.2 had:

"If a matching mapped list item is not found, the assigned initial value of the
pointer is NULL unless otherwise specified (see Section 2.5.1)."

* * *

The attached testcase shows that 'p1' and 'p2' are NULL instead of the
expected value.

→ Usage case 'p2' is one where it seems to make sense to keep the value
→ The issue came up with (unified-)shared memory where mapping still has to
  work – at least as long as omp_target_associate_ptr does not fail when
  host/device pointers differ as this really requires keeping track of mapping.
→ See OpenMP Issue #2604 for the spec change.


* * *

Note that firstprivate(p1,p1) / defaultmap(firstprivate:pointer)
are different to the (implicit) 'defaultmap(default:pointer)' used in the
attached testcase due to the wording quoted above, which only applies with
'default'.

Related: PR109837 (requires unified_address testcase), which provides the
existing testcase mentioned above.

Cf. also "5.8.1 Implicit Data-Mapping Attribute Rules" which has:

"A variable that is of type pointer [...] is treated as if it is the
base pointer of a zero-length array section that had appeared as a
list item in a map clause."

* * *

On the technical side, GCC creates – in line with the last quote:
 map(alloc:MEM[(char *)p3] [len: 0]) map(firstprivate:p3 [pointer assign, bias:
0])
which in lower_omp_target is changed to:
  if (OMP_CLAUSE_MAP_MAYBE_ZERO_LENGTH_ARRAY_SECTION (c))
...
    tkind_zero = GOMP_MAP_ZERO_LEN_ARRAY_SECTION;

TODO/Expected:
In libgomp, we now need to ensure that the pointer's value gets copied and is
not set to NULL.

[Bug middle-end/110270] [OpenMP] OpenMP 5.2 – firstprivate of pointer shall retain the value if pointee is not mapped

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:b25ea7ab78cdb7baec694e56eadb71002726a73e

commit r14-1923-gb25ea7ab78cdb7baec694e56eadb71002726a73e
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Mon Jun 19 09:08:51 2023 +0200

    OpenMP (C/C++): Keep pointer value of unmapped ptr with default mapping
[PR110270]

    For C/C++ pointers, default implicit mapping firstprivatizes the pointer
    but if the memory it points to is mapped, the it is updated to point to
    the device memory (by attaching a zero sized array section of the
pointed-to
    storage).

    However, if the pointed-to storage wasn't mapped, the pointer was set to
    NULL on the device side (OpenMP 5.0/5.1 semantic). With this commit, the
    pointer retains the on-host address in that case (OpenMP 5.2 semantic).

    The new semantic avoids an explicit map/firstprivate/is_device_ptr in the
    following sensible cases: Special values (e.g. pointer or 0x1, 0x2 etc.),
    explicitly device allocated memory (e.g. omp_target_alloc), and with
    (unified) shared memory.
    (Note: With (U)SM, mappings still must be tracked, at least when
    omp_target_associate_ptr does not fail when passing in two destinct
pointers.)

    libgomp/

            PR middle-end/110270
            * target.c (gomp_map_vars_internal): Copy host value instead of
NULL
            for  GOMP_MAP_ZERO_LEN_ARRAY_SECTION if not mapped.
            * libgomp.texi (OpenMP 5.2 Impl.): Mark as 'Y'.
            * testsuite/libgomp.c/target-19.c: Update expected value.
            * testsuite/libgomp.c++/target-18.C: Likewise.
            * testsuite/libgomp.c++/target-19.C: Likewise.
            * testsuite/libgomp.c-c++-common/requires-unified-addr-2.c: New
test.
            * testsuite/libgomp.c-c++-common/target-implicit-map-3.c: New test.
            * testsuite/libgomp.c-c++-common/target-implicit-map-4.c: New test.

[Bug middle-end/110270] [OpenMP] OpenMP 5.2 – firstprivate of pointer shall retain the value if pointee is not mapped

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
FIXED — for GCC mainline = 14.