[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1416760143.16006.460.camel@eris.loria.fr>
Date: Sun, 23 Nov 2014 17:29:03 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add stdatomic.h for clang>=3.1 and gcc>=4.1
Am Sonntag, den 23.11.2014, 10:21 -0500 schrieb Rich Felker:
> On Sun, Nov 23, 2014 at 10:43:34AM +0100, Jens Gustedt wrote:
> > Hello,
> >
> > Am Sonntag, den 23.11.2014, 02:47 +0100 schrieb Joakim Sindholt:
> > > GCC 4.9:
> > >
> > > typedef _Atomic struct
> > > {
> > > #if __GCC_ATOMIC_TEST_AND_SET_TRUEVAL == 1
> > > _Bool __val;
> > > #else
> > > unsigned char __val;
> > > #endif
> > > } atomic_flag;
> > >
> > > Clang 3.6:
> > >
> > > #ifdef __cplusplus
> > > typedef _Atomic(bool) atomic_bool;
> > > #else
> > > typedef _Atomic(_Bool) atomic_bool;
> > > #endif
> > >
> > > typedef struct atomic_flag { atomic_bool _Value; } atomic_flag;
> >
> > So they fucked it up and have incompatible declarations? Great.
>
> The differences are minor, and are things that are generally
> considered non-issues when linking code from two different
> compilers/implementations of the language which share an ABI. The only
> differences are the name of the member (__val vs _Value) and whether
> its type is atomic-qualified. I agree there's room for different
> interpretations, but my view is that when you're linking code produced
> by different compilers that have agreed on an ABI, matching the
> size/representation/layout is generally sufficient.
I wouldn't exactly call that "have agreed on an ABI", but be it. Since
this behavior is undefined by the standard, they'd have to document
that as implementation defined behavior.
> > For the discussion about the second case for the type, this is the
> > question if there are archs that implement TAS operations with other
> > values than 0 for "unset" and 1 for "set". There seem to be archs out
> > there that implement TAS with other values, I vaguely remember having
> > heard about some risk arch (??). Actually this also is the reason why
> > the standard defines this type in such a weird manner, and why per the
> > standard it needs a dedicated initialization macro, default
> > initialization with 0 doesn't do in all cases.
>
> These are not archs we can support with musl, so they wouldn't be
> relevant. And they're not archs that could support POSIX without a
> kernel stop-the-world approach for implementing CAS, or syscalls for
> every synchronization action.
Could you be more specific? Is it that you know that all the arch in
question and conclude about their behavior from you knowledge about
them?
Without more specific information I don't see any reason, that an arch
that has such specialized super-fast TAS with weird values couldn't
have a CAS that behaves "normal". But then I also don't see any reason
for such a TAS design in any case ...
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
