[Bug libstdc++/71660] [5/6/7/8 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86

[peter at cordes dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660

--- Comment #13 from Peter Cordes <peter at cordes dot ca> ---
(In reply to Thiago Macieira from comment #12)
> Another problem is that we've now had a couple of years with this issue, so
> it's probably worse to make a change again.

A change to C++11 std::atomic?  Yeah, we definitely should not change it.  It's
using by far the most efficient solution for code that does any pure-store or
pure-load operations, and any change would break that.

It's also compatible with clang (at least as far as struct layout and how
whether or not 64-bit atomic objects are lock-free).

Also, it's interoperable with 64-bit std::atomic for shared-memory segments, if
you avoid struct layout differences for non-atomic 64-bit struct members.

If you want a struct with non-atomic members to match the layout of a struct
with atomic members, do something like

struct foo {
    char c;
    alignas(atomic<long long>) long long t;
};

And usually sort your struct members largest-first to reduce padding in the
first place.

Maybe there's some other case that makes it convenient for minimum alignment
(C11 _Alignof) atomic types to match _Alignof non-atomic types?  Note that
gcc's implementation of C++11/14 alignof doesn't match it's C11 _Alignof
behaviour.  g++ alignof gives you the "recommended" alignment, like
__alignof__, rather than the minimum where you will ever find a value of this
type.  See https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00435.html and bug
52023 for the reasons behind changing C11 _Alignof but not C++14 alignof.  (On
reading the standard, I'm not sure I agree;  I think C++14 should be returning
4 for alignof(long long) with -m32 in the SysV ABI.)

IDK what Qt's assert is guarding against.  If you're specifically worried about
atomicity, checking that alignof(InStruct) == sizeof(long long) makes more
sense, because that's required on almost any architecture as a guaranteed way
to avoid cache-line splits.  (C/C++ don't have a simple way to express
"unaligned is fine except at cache line boundaries" like you get on Intel
specifically (not AMD)).