[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Sep 6 12:01:28 GMT 2021


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually, looking at GCN, it is inline e.g. for both:

int
foo (int *p)
{
  return __sync_val_compare_and_swap_4 (p, 1, 2);
}

int
bar (int *p)
{
  int e = 1;
  __atomic_compare_exchange_4 (p, &e, 2, 0, __ATOMIC_SEQ_CST,
__ATOMIC_SEQ_CST);
  return e;
}

but for 1 or 2 byte atomics it is never inline:

int
foo (char *p)
{
  return __sync_val_compare_and_swap_1 (p, 1, 2);
}

int
bar (char *p)
{
  char e = 1;
  __atomic_compare_exchange_1 (p, &e, 2, 0, __ATOMIC_SEQ_CST,
__ATOMIC_SEQ_CST);
  return e;
}


The reason why foo in the second testcase works is libgcc/config/gcn/atomic.c
which defines __sync_{val,bool}_compare_and_swap_{1,2}.

So, either it should also define __atomic_compare_exchange_{1,2} perhaps with
calling __sync_val_compare_and_swap_{1,2} under the hood or the other way
around, or the backend somewhere needs to rewrite calls to
__atomic_compare_exchange_{1,2} into calls to __sync_*_compare_and_swap_{1,2}.

The reason why I've changed omp-expand is that by using __atomic_* APIs one can
use the user-requested memory models, and once the 5.1 atomics support is done,
there will be more - weak flag too, and user specified failure memory models.


More information about the Gcc-bugs mailing list