https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #27 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- (In reply to Jonathan Wakely from comment #24) > (In reply to Hans-Peter Nilsson from comment #22) > > Or do I misread that? Are __alignof(x) and the result of alignas(x) > > in the declaration guaranteed to always be the same here? > > Yes. For the combination of alignof and alignas in *this* code it's not obvious to me. I can imagine that (for example) the alignment of a container can affect the __alignof(x) such that it's (for example) higher than the specifically alignas declaration of x, likely by bug, less likely by intent. IOW, to me, this isn't the alignas(type) === alignas(alignof(type)) in <https://en.cppreference.com/w/cpp/language/alignas>. Either way, whether the guarantee is by C++ standard wording or by gcc internals documentation carries not more value than the documentation for __atomic_is_lock_free when it comes to maintainer reading, heh... So, what I'd like to see is either: - This change in atomic_base.h, avoiding use of the specific object in is_lock_free and changing to __atomic_always_lock_free: Index: atomic_base.h =================================================================== --- atomic_base.h (revision 264855) +++ atomic_base.h (working copy) @@ -355,7 +355,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION { // Use a fake, minimally aligned pointer. return __atomic_is_lock_free(sizeof(_M_i), - reinterpret_cast<void *>(-__alignof(_M_i))); + reinterpret_cast<void *>(-_S_alignment)); } bool @@ -363,7 +363,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION { // Use a fake, minimally aligned pointer. return __atomic_always_lock_free(sizeof(_M_i), - reinterpret_cast<void *>(-__alignof(_M_i))); + reinterpret_cast<void *>(-_S_alignment)); } _GLIBCXX_ALWAYS_INLINE void (Note the change to __atomic_always_lock_free. BTW, why use __alignof and not alignof? No underscores in the _S_alignment expression!) -or- - at least a test in the C++ test-suite with at least a construct of the exact same form as the one in atomic_base.h but with an overaligned container and an assert that the alignof the inner object equals the alignas expression, as you asserted above. I know that'd cover only the first case of alignment-bleed that comes to mind, but it'd indicate an intent to future hackers. - optionally: wording in the gcc documentation to the effect of the __alignof === alignas guarantee. (Still, a test-case is more reliable than gcc documentation.) But, there's probably sufficient wording in the standard. Maybe some of that is already in place; if it isn't, I'll produce patches (and CC you, hoping for speedier review). Do we have common ground here?
