https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> --- Comment on attachment 44851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44851 patch as per directions That looks like sufficient variety of types tested. I would prefer a function template instead of the LF macro e.g. template<typename T> void check() { std::atomic<T> a; VERIFY( a.is_lock_free() || !a.is_always_lock_free ); } and then: check< Foo * >(); check< Bar * >(); etc. But I'm losing confidence in this change being correct, after asking some questions of the C++ committee. The intent seems to be that is_lock_free() can indeed give a runtime answer, based on properties which might not have been known at compile-time. For example, code compiled with -march=i386 will say is_always_lock_free is false (correctly) but if at runtime it links to libatomic compiled for i686 and it runs on i686 then is_lock_free could return true. So the link failure in comment 30 is right, and I was wrong to say: > The result should be the same as ax.is_always_lock_free which is a constant. This is the point Andrew made all the way back in Comment 2. At compile-time we might not be able to guarantee lock-freedom, but at run-time libatomic might be able to **and that will be true for all suitably-aligned objects of that type**. So the premise that "is_lock_free() is per-type implies it's the same as always_lock_free" is wrong.