Hi! On 2020-08-12T15:57:23+0200, Tom de Vries <tdevr...@suse.de> wrote: > When enabling sync_int_long for nvptx, we run into a failure in > gcc.dg/pr86314.c: > ... > nvptx-run: error getting kernel result: operation not supported on \ > global/shared address space > ... > due to a ptx restriction: accesses to local memory are illegal, and the > test-case does an atomic operation on a stack address, which is mapped to > local memory.
Now, that problem also is easy to reproduce in an OpenACC/nvptx offloading setting. (..., as Julian had reported and analyzed in an internal "Date: Fri, 31 May 2019 00:29:17 +0100" email, similar to Tom's comments in PR96494 "[nvptx] Enable effective target sync_int_long" and PR97444 "[nvptx] stack atomics".) > Fix this by adding a target sync_int_long_stack, wich returns false for nvptx, > which can be used to mark test-cases that require sync_int_long support for > stack address. Similar to PR97444 "[nvptx] stack atomics", such a conditional is of course not applicable for the OpenACC implementation, so to at least document/test/XFAIL nvptx offloading: PR83812 "operation not supported on global/shared address space", I've now pushed to master branch "Add 'libgomp.oacc-c-c++-common/private-atomic-1.c' [PR83812]" in commit 1467100fc72562a59f70cdd4e05f6c810d1fadcc, see attached. And then, I got back testresults from one more system, and I've filed <https://gcc.gnu.org/PR100678> "[OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations"... :-\ As it's not clear yet what the conditions are, I cannot come up with a selector to (differently) XFAIL that one. Grüße Thomas ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf
