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
