On 3/26/26 11:43, Tobias Burnus wrote:
This patch fixes some corner cases issues with the two routines; it
is rather simple and only affects those (mainly: NULL and USM use).
Plus tweaks the documentation a bit.
Seemingly, there was some confusion whether being host accessible also
counts as being 'present', but the routines should only work with
actually mapped (corresponding storage). Additionally, some corner cases
like whether a NULL pointer is present were clarified (it is not).
(For the get_mapped function, it has only been moved to avoid going
to locking etc. when the result is known: NULL is always NULL, whether
being the original pointer or being a way to denote an error.)
And for unified-shared memory, some tweaking was required, especially as
some memory still has corresponding storage: all memory with 'declare target',
except for the 'link' clause for which we link to the host memory.
The 'link' clause handling has also been clarified in the manual; it
is not completely clear to me whether the pointer or pointee should
be regarded in this case, either kind of makes sense. Documented is
now what GCC does, which seems to make sense.
In particular, the commit fixes a wrong-code and potential crash issue
for code like the following; the first one has been taken from such a
code and failed with 'requires unified_shared_memory':
if (omp_target_is_present(D, default_device_omp_target_call)) {
int rc = omp_target_disassociate_ptr(D, default_device_omp_target_call);
also affected would be code such as:
if (omp_target_is_present (...)
omp_target_memcpy (omp_get_mapped_ptr (ptr), ptr, ...);
Comment, questions, concerns before it gets applied?
I spotted a few nits in the documentation part.
@@ -2657,13 +2649,20 @@ is not supported.
@subsection @code{omp_get_mapped_ptr} -- Return device pointer to a host
pointer
@table @asis
@item @emph{Description}:
-If the device number is refers to the initial device or to a device with
-memory accessible from the host (shared memory), the @code{omp_get_mapped_ptr}
+If the device number is refers to the initial device, the
@code{omp_get_mapped_ptr}
routines returns the value of the passed @var{ptr}. Otherwise, if associated
s/is refers/refers/
s/the @code{omp_get_mapped_ptr} routines
returns/@code{omp_get_mapped_ptr} returns/
storage to the passed host pointer @var{ptr} exists on device associated with
@var{device_num}, it returns that pointer. In all other cases and in cases of
an error, a null pointer is returned.
+If the device number is not the initial device and the pointer points to a
+variable that is specified in a @code{declare target} directive: When
+requiring @code{unified_shared_memory} or @code{self_maps}, a null pointer is
+returned if the variable appeared in a @code{link} or @code{enter} clause.
I think s/appeared/appears/ here, to follow the general rule of writing
in the present tense. It doesn't seem to be directly contrasting
compile-time vs run-time behavior, at least.
+Otherwise, the corresponding device memory is returned; with the @code{link}
+clause, GCC returns the address of the pointer-typed link variable on the
device
s/on the device/on the device,/
+not to the data that is mapped to that variable.
+
The association of storage location is established either via an explicit or
implicit @code{map} clause, the @code{declare target} directive or the
@code{omp_target_associate_ptr} routine.
-Sandra
