Hi!
On 2026-01-05T09:49:46+0000, Andrew Stubbs <[email protected]> wrote:
> On 24/12/2025 09:59, Thomas Schwinge wrote:
>> This was added in commit 1cf9fda4936de54198858b8f54cd9707a3725f4e
>> "amdgcn: Adjust failure mode for gfx908 USM".
>>
>> In a GCC configuration with both AMD and NVIDIA GPU code offloading
>> supported,
>> and the selected AMD GPU code generation not supporting USM, but an
>> USM-capable
>> NVIDIA GPU available, I see all test cases that require effective-target
>> 'omp_usm' turn UNSUPPORTED, because:
>>
>> Executing on host: gcc usm_available_2778376.c [...]
>> [...]
>> In function 'main._omp_fn.0':
>> lto1: warning: Unified Shared Memory is required, but XNACK is disabled
>> lto1: note: Try -foffload-options=-mxnack=any
>> gcn mkoffload: warning: conflicting settings; XNACK is forced off but
>> Unified Shared Memory is required
>> UNSUPPORTED: [...]
>>
>> That warning is, however, not relevant in the scenario described above: we're
>> not going to exercise AMD GPU code offloading at run time.
>>
>> With the effective-target 'omp_usm' check robustified like this, the affected
>> test cases are then no longer UNSUPPORTED, but of course, there's then the
>> corollary issue that compilation of the test case itself now emits the very
>> same warning, which results in the "test for excess errors" FAILing, despite
>> the execution test PASSing, for example:
>>
>> FAIL: libgomp.c++/target-std__valarray-concurrent-usm.C (test for
>> excess errors)
>> PASS: libgomp.c++/target-std__valarray-concurrent-usm.C execution test
>>
>> That's clearly not ideal either (but is representative of what real-world
>> usage
>> would run into), but is certainly better than the whole test case turning
>> UNSUPPORTED. To be continued, I guess...
>>
>> libgomp/
>> * testsuite/lib/libgomp.exp (check_effective_target_omp_usm):
>> Robustify.
>> ---
>> libgomp/testsuite/lib/libgomp.exp | 14 +++++++++++---
>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/libgomp/testsuite/lib/libgomp.exp
>> b/libgomp/testsuite/lib/libgomp.exp
>> index cce2e93f857..93e2a681cb4 100644
>> --- a/libgomp/testsuite/lib/libgomp.exp
>> +++ b/libgomp/testsuite/lib/libgomp.exp
>> @@ -728,8 +728,16 @@ int main() {
>> # return 1 if OpenMP Unified Shared Memory is supported by offload devices
>>
>> proc check_effective_target_omp_usm { } {
>> - if { [check_effective_target_offload_device_nvptx]
>> - || [check_effective_target_offload_target_amdgcn] } {
>> + set flags ""
>> + if { [check_effective_target_offload_target_amdgcn] } {
>> + # Specify '-mxnack=any' to inhibit GCN offloading compilation
>> + # 'warning: Unified Shared Memory is required, but XNACK is disabled'.
>> + # This run-time effective-target check shouldn't fail in case there's
>> + # actually no AMD GPU, but there's an USM-capable NVIDIA GPU.
>> + lappend flags "-foffload-options=amdgcn-amdhsa=-mxnack=any"
>> + }
>
> Did you test this on gfx1100?
Sure.
> This looks like it will break on any
> device which doesn't support the XNACK feature at all.
No, because in that case, '-mxnack=any' is mapped to '-mxnack=off'
silently; 'gcc/config/gcn/gcn.cc:gcn_option_override':
/* gfx1030 and gfx1100 do not support XNACK. */
if (gcn_devices[gcn_arch].xnack_default == HSACO_ATTR_UNSUPPORTED)
{
if (flag_xnack == HSACO_ATTR_ON)
error ("%<-mxnack=on%> is incompatible with %<-march=%s%>",
gcn_devices[gcn_arch].name);
/* Allow HSACO_ATTR_ANY silently. */
flag_xnack = HSACO_ATTR_UNSUPPORTED;
}
> As it happens,
> that's probably fine for gfx1100, specifically, because that device
> doesn't support USM, but there may well be another device that supports
> USM without XNACK (anything with truly shared memory, perhaps).
I'm sorry, I don't understand that concern/scenario?
Grüße
Thomas
>> + if { $flags != ""
>> + || [check_effective_target_offload_device_nvptx] } {
>> if [check_runtime usm_available_ {
>> #include <omp.h>
>> #pragma omp requires unified_shared_memory
>> @@ -740,7 +748,7 @@ proc check_effective_target_omp_usm { } {
>> a = omp_is_initial_device ();
>> return a;
>> }
>> - } ] {
>> + } "$flags" ] {
>> return 1
>> }
>> }
