armv5 Linux systems implement __sync_bool_compare_and_swap() and friends by calling a function provided by the kernel. This is not technically an atomic intrinsic, so gcc doesn't define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 in this case, but it's good enough for us. Extend the current Android special case to cover GNU/Linux too.
The possibilities are:
-
__sync_foo detected and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 predefined: calls to __atomic_foo or __sync_foo primitives are inlined into user code by gatomic.h
-
__sync_foo detected but __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 not predefined: user code has an extern reference to g_atomic_foo(), which calls __atomic_foo or __sync_foo because we defined __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 when compiling GLib itself
-
Windows: user code has an extern reference to g_atomic_foo(), which calls InterlockedFoo()
-
!defined(G_ATOMIC_LOCK_FREE): user code has an extern reference to g_atomic_foo(), which emulates atomic operations with a mutex
Closes #1576 (closed)
Testing still needed:
-
Test on Debian armel (armv5 EABI softfloat) -
Test on Debian armhf (armv7 EABI hardfloat)