http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> 2012-08-08 15:04:21 UTC --- I don't think that is right. A type may not be always lock free from the compiler's perspective, so __atomic_always_lock_free() will return false. The compiler will issue a call to libatomic to implement any atomic operations, and libatomic may provide a lock-free implementation for the type/size. So these need to remain runtime calls to __atomic_is_lock_free () since the question cannot always be answered at compile time. In cases where __atomic_always_lock_free() is true at compile time, __atomic_is_lock_free() will return a compile time true. The runtime call is only made when __atomic_always_lock_free is false.
