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.