https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #29 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Hans-Peter Nilsson from comment #27) > (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 What do you mean by container? The std::atomic class template? > can affect the __alignof(x) such that it's (for example) > higher than the specifically alignas declaration of x, likely by bug, Yes, that would be a compiler 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>. Because we're not relying on that. We're using GCC's __alignof extension to ask for the alignment of an lvalue object, not a type. https://gcc.gnu.org/onlinedocs/gcc/Alignment.html That page should probably be amended to also mention 'alignas' when it says "taking into account any minimum alignment specified with GCC’s __attribute__ extension". The alignas(_S_alignment) specifies the alignment for the _M_i member, and __alignof gives that same value back. We could verify that with: static_assert(__alignof(_M_i) == _S_alignment, "sanity check"); Given the history of bugs in this code, I'm reluctant to make any larger changes here without a test showing an actual bug.
