Re: Purpose of USE_ATOMIC_COMPILER_BUILTINS

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 17 Nov 2015, Florian Weimer wrote:

> One advantage of using <stdatomic.h> is that we can use published C11
> material as the documentation, and we do not have to write our own.

<stdatomic.h> requires GCC 4.9 or later and is intended to be used with 
_Atomic types (and it's far from obvious that the implicit magic involved 
with those types, as opposed to atomic operations on normal types, is 
right for glibc).

> Which architectures are supported by glibc, have SMP implementations
> (even EOLed ones), but do not have a useful CAS?  Even PA-RISC has a CAS
> in libgcc (with kernel assist).  Plain i386 is already unsupported for
> SMP, I think, although there were some SMP systems at one point.

You can assume a CAS, possibly kernel-assisted[*] and possibly 
out-of-line, and, if inline, possibly with less-efficient barriers than 
the inline asm (see: MIPS __atomic_* only being optimized regarding 
barriers in GCC 4.8).  I'm not aware of any guarantees around when an 
out-of-line call will be to a libatomic function versus a libgcc one; if 
we want to rely on certain __atomic_* calls generating out-of-line calls 
to __sync_* (libgcc) not __atomic_* (libatomic) that would require further 
investigation and documentation.  And CAS in glibc on older sparc32 
involves global locks, which I don't think the GCC built-in functions will 
do.

[*] Approaches for kernel assistance include instruction emulation, 
syscalls, magic pages at specific addresses, vDSO and restartable 
sequences, at least; maybe others.

It might be hard for libgcc to use a vDSO-based CAS, but I'm not sure the 
vDSO atomics kernel patches for ColdFire ever got merged anyway.

I think the first priorities regarding USE_ATOMIC_COMPILER_BUILTINS should 
be converting more architectures to use it at least in the cases where the 
code will be expanded inline, and reducing the amount of code present in 
architecture-specific atomic-machine.h files when 
USE_ATOMIC_COMPILER_BUILTINS is defined (why should they need anything 
more than USE_ATOMIC_COMPILER_BUILTINS and __HAVE_64B_ATOMICS?).  Cases 
involving libgcc functions will involve more careful examination of what 
supported GCC versions do with __atomic_* calls in such cases, and 
additions to GCC documentation to make guarantees around when libgcc 
functions rather than libatomic functions will be called.

-- 
Joseph S. Myers
joseph@codesourcery.com