[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" <gcc-bugzilla@gcc.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.