atomics

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

To quote https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html :
   __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1
   __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
   __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
   __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
   __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16

   These macros are defined when the target processor supports
   atomic compare and swap operations on operands 1, 2, 4, 8 or
   16 bytes in length, respectively.

and https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html :

   bool __sync_bool_compare_and_swap (type *ptr, type oldval, type newval, ...)
   type __sync_val_compare_and_swap (type *ptr, type oldval, type newval, ...)

   These built-in functions perform an atomic compare and swap.
   That is, if the current value of *ptr is oldval, then write
   newval into *ptr.

   The â??boolâ?? version returns true if the comparison is successful
   and newval is written. The â??valâ?? version returns the contents
   of *ptr before the operation.

glib's code started life insisting that both __sync_bool_compare_and_swap()
and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 must be defined for gatomic.c to
not fall back to pthread_mutex_lock using code.

I haven't found any documentation linking the macro and the function.

PR pkg/54298 (http://gnats.netbsd.org/54298) shows earm and sparc
having the function but not the macro.

glib then decided to define the macro itself on android, and then later
on linux. (A fix for us would therefore also be to ignore the macro.)

Does this mean that the macro is meaningless? Comments?


Cheers,

Patrick