Re: implement stdatomic.h library interface

[Szabolcs Nagy <nsz@port70.net>]

* Jens Gustedt <jens.gustedt@inria.fr> [2015-07-23 11:58:28 +0200]:
> Looking back on this, I think that we had a bit of a wrong focus,
> then. The point for musl wouldn't necessarily be to provide the
> <stdatomic.h> header itself, but the stub functions that are needed if
> the compiler isn't able to inline all operations.
> 
> Since I needed it, now, I just went for it and implemented it. For the
> moment this isn't integrated to musl but standalone, and for a proper
> integration into musl I'd still have some work to do.
> 
> At the moment I see three principal possibilities for improvement with
> atomics in musl:
> 
> (1) Provide the library interfaces that gcc >= 4.8 and clang > 3.6 (?)
>     need. The interface is well documented, so let's just do it.
> 
> (2) Provide an interface to atomics for compilers that don't have it
>     yet. This can be done more or less easily up to some limits for
>     all compilers that implement the __sync builtins. gcc 4.8 is a bit
>     special since it implements the atomic operations but not the type
>     qualification.
> 

so you plan to implement gcc libatomic abi in musl?

it seems gcc does not pass -latomic automatically to the linker
which is ugly (i think atomics should work transparently), but
ppl using atomics will.

(there is another problem that gcc libatomic on x86 uses ifunc
dispatch for some __atomic_*_16 functions which does not work
with musl now, this can be worked around by rebuilding gcc with
--disable-gnu-indirect-function.)

>     For compilers that don't have __sync or __atomic we could provide
>     a minimal interface with lock-free _Atomic(int), _Atomic(void*)
>     and atomic_flag, say.
> 
>     The limits for these platforms would be that code could only use
>     the _Atomic(bla) specification for the types and macro calls to
>     act upon them. But since for pre-C11 compilers this is just an
>     extension, that would be a start.
> 
> (3) Review the internal use of atomics. AFAIR, Rich has already
>     started to look into that, but in any case that part is probably
>     independent of the first two points.
> 
>     In a later stage, once (1) and (2) are stable, we could then look
>     into using _Atomic(int) and the corresponding macros.
> 
> Jens
> 
> 
> -- 
> :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
> :: ::::::::::::::: office Strasbourg : +33 368854536   ::
> :: :::::::::::::::::::::: gsm France : +33 651400183   ::
> :: ::::::::::::::: gsm international : +49 15737185122 ::
> :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
> 
> 
> 
>