This is the mail archive of the
mailing list for the GCC project.
Re: [v3] updated atomic configury
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Mon, 21 Nov 2011 23:02:30 -0500
- Subject: Re: [v3] updated atomic configury
- References: <20111121182914.76e9cde9@shotwell>
On 11/21/2011 09:29 PM, Benjamin Kosnik wrote:
Here's the first step in making the libstdc++ atomic configure bits into
something that makes more sense. This consolidates the builtin parts of
the configury, such that builtins mean C++11 atomics, not C++11 atomics
mixed with pre-C++11 atomics.
I think this is mostly right, modulo my logic on the equivalency of
ATOMIC_INT_LOCK_FREE == _GLIBCXX_ATOMIC_BUILTINS_4. This is something
that should hold, IMHO.
Well, I guess it should. _GLIBCXX_ATOMIC_BUILTINS_4 is defined as an
'int' in the configure file, even if an 'int' isn't 4 bytes for some
target. So that should work for backwards compatibility.
If you really want it to be 4 bytes you would have to use
__atomic_always_lock_free (4) then its not dependent on the sizeof(int).
I was expecting
the C++11 macros for lock-free properties, ie ATOMIC_BOOL_LOCK_FREE to
be either 0, 1, 2, and to be able to use them like:
#if (ATOMIC_INT_LOCK_FREE> 1)
// yes, cool, yeah!
But this doesn't seem to work. And what I have in this patch, which is
That should work. The __atomic_always_lock_free(X) does fold to a
compile time constant... but perhaps it doesn't fold early enough to be
used by the preprocessor?
oh, I see you changed it to:
#define __LOCK_FREE_PROPERTY(T) (__atomic_always_lock_free(sizeof(T), 0) ? 2 : __atomic_is_lock_free(sizeof(T)))
The problem with that is that under the new regime, if an atomic size is
not *always* lock free, then __atomic_is_lock_free() becomes a runtime
libary call. So this definition you have will resolve to either a 2,
or a runtime function call.
All we can now tell at compile time is whether something is a 2 or
not. __atomic_always_lock_free() was created to be the compile time
version that never resolves to a library call, so you can set the macro
to either 2 if its true, or 1 if its false like I had before. we will
never, ever, set the macro to a value of 0.
Anyway, it looks like __atomic_always_lock_free doesn't fold early
enough to be usable by the preprocessor like that even with my earlier
version. ugg. I think I can get something defined in cpp-builtins that
we can use. We're going to need it for C1x next release anyway.
Should be ready to try tomorrow sometime.