https://gcc.gnu.org/g:5f6257c26b814de1a14c71b2d3a49291765b6577
commit r17-3979-g5f6257c26b814de1a14c71b2d3a49291765b6577 Author: Tobias Burnus <[email protected]> Date: Mon Sep 7 21:06:01 2026 +0200 libgomp.texi: Improve the wording for GOMP_RUNTIME_USM, update impl status The need_device_addr modified is supported for C (always an error) since r15-6178-g2cbb2408a830a6 and in Fortran r15-7595-g8268c8256dd430. [The C++ support exists on the devel/omp branches, but some cleanup is required for upstreaming.] libgomp/ChangeLog: * libgomp.texi (OpenMP 6.0 implementation status): Mark 'need_device_addr' as supported. (GOMP_RUNTIME_USM): Improve wording of the unsupported part. Diff: --- libgomp/libgomp.texi | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi index a358f347fed1..190872f299f6 100644 --- a/libgomp/libgomp.texi +++ b/libgomp/libgomp.texi @@ -544,7 +544,8 @@ to address of matching mapped list item per 5.1, Sect. 2.21.7.2 @tab N @tab @item New @code{partitioner} value to @code{partition} allocator trait @tab N @tab @item Semicolon-separated list to @code{uses_allocators} @tab Y @tab -@item New @code{need_device_addr} modifier to @code{adjust_args} clause @tab N @tab +@item New @code{need_device_addr} modifier to @code{adjust_args} clause @tab P + @tab Not supported in C++ @item @code{interop} clause to @code{dispatch} @tab Y @tab @item Scope requirement changes for @code{declare_target} @tab N @tab @item @code{message} and @code{severity} clauses to @code{parallel} directive @@ -5254,24 +5255,22 @@ default. Setting it to @code{AUTO} conditionally enables Unified Shared Memory (USM) on specific integrated GPUs (APUs, in the verbiage of AMD). In most workloads on these types of GPUs, self-mapping is expected to reduce runtime overhead. Lastly, setting it to @code{ENABLED} unconditionally attempts -to make use of Unified Shared Memory if the device claims to support it. Of -additional note, specifying the @code{unified_shared_memory} or -@code{self_maps} clauses with the @code{requires} directive causes that -behavior to take precedence over the behavior set by this environment -variable. For caveats around Unified Shared Memory, please consult -the relevant sections in @ref{Offload-Target Specifics}. - -When unified-shared memory is enabled by this environment variable, the -following is currently @emph{unsupported} for only global static variables -that are specified in an @code{enter} clause on a @code{declare target} -directive: specifying those variables in a @code{map} clause with @code{always} -modifier on a @code{target} or @code{target data} directive. However, both -@code{map} clauses without @code{always} modifier and using the -@code{target update}, @code{target enter data}, or @code{target exit data} -directives is fully supported. When the unsupported case is -encountered, the program aborts with an error message. +to make use of Unified Shared Memory if the device claims to support it. +For general caveats around Unified Shared Memory, please consult the relevant +sections in @ref{Offload-Target Specifics}. + +When Unified Shared Memory is enabled by this environment variable, the +following is currently @emph{unsupported}: using a global static variable, +specified in an @code{enter} clause on a @code{declare target}, in a +@code{map} clause with @code{always} modifier on either a @code{target} or +a @code{target data} directive. When the unsupported case is encountered, +the program aborts with an error message. @c FIXME: This is tracked in PR libgomp/127186 +When specifying the @code{unified_shared_memory} or @code{self_maps} clauses +with the @code{requires} directive causes that behavior to take precedence +over the behavior set by this environment variable. + OpenACC is unaffected by the value of this environment variable, however, hybrid usage of OpenMP and OpenACC offloading results in the first used framework taking precedent. As an example, if one uses OpenMP offloading and
