[libgomp, nvptx] Add __sync_compare_and_swap_16
authorTom de Vries <tdevries@suse.de>
Sat, 5 Sep 2020 10:45:07 +0000 (12:45 +0200)
committerTom de Vries <tdevries@suse.de>
Mon, 14 Sep 2020 06:28:56 +0000 (08:28 +0200)
commit4ac7b66958016225724084078e6e7937e23ffcd3
tree47204c1ed494cf156f9f786f4956c587199e487b
parent919858077f4b768c8472f29b977edf0aa6e0f1e5
[libgomp, nvptx] Add __sync_compare_and_swap_16

As reported here
( https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553070.html  ),
when running test-case libgomp.c-c++-common/reduction-16.c for powerpc host
with nvptx accelerator, we run into:
...
unresolved symbol __sync_val_compare_and_swap_16
...

I can reproduce the problem on x86_64 with a trigger patch that:
- initializes ix86_isa_flags2 to TARGET_ISA2_CX16
- enables define_expand "atomic_load<mode>" in gcc/config/i386/sync.md
  for TImode

The problem is that omp-expand.c generates atomic builtin calls based on
checks whether those are supported on the host, which forces the target to
support these, even though those checks fail for the accelerator target.

Fix this by:
- adding a __sync_val_compare_and_swap_16 in libgomp for nvptx,
  which falls back onto libatomic's __atomic_compare_and_swap_16
- adding -foffload=-latomic in the test-case

Tested libgomp on x86_64-linux with nvptx accelerator.

Tested libgomp with trigger patch on x86_64-linux with nvptx accelerator.

libgomp/ChangeLog:

* config/nvptx/atomic.c: New file.  Add
__sync_val_compare_and_swap_16.
* testsuite/libgomp.c-c++-common/reduction-16.c: Add -latomic for
target offload_target_nvptx.
libgomp/config/nvptx/atomic.c [new file with mode: 0644]
libgomp/testsuite/libgomp.c-c++-common/reduction-16.c