[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[amacleod at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005

--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> 2012-08-14 03:20:09 UTC ---

A GCC port is incorrect if it is issuing any kind of lock.  GCC is only allowed
to issue a lock free sequence of some sort.  If a lock is required, then a call
to libatomic must be made.

So if there is a type which is sometimes lock free and sometimes not due to
alignment or anything else,   __atomic_always_lock_free should return FALSE for
that type.  I think your current problem is that the infrastructure change for
__atomic_always_lock_free to handle alignment issues is not present yet. So it
erroneously says TRUE for this type when in fact it shouldn't.   

I don't think this will be resolved properly in GCC 4.7 since c++11 is still
experimental (I could be wrong, we'll see how invasive the support changes
are).


Its important that the libstdc++ routines call the __atomic_is_lock_free() so
that the answer can be determined at runtime if libatomic is utilized for any
atomic sequences. 

__atomic_always_lock_free() is *always* resolved to a 1 or a 0 at compile time.
The compiler is only capable of answering the question, "Does the compiler
always generate a lock free sequence".    

__atomic_is_lock_free() will return true if __atomic_always_lock_free() returns
true. Otherwise it is left as a runtime call into libatomic so it can answer
the q.  libatomic is