This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] updated atomic configury


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!
#endif

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.

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]