This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/71660] [5/6/7/8 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86
- From: "thiago at kde dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 05 Sep 2017 14:24:14 +0000
- Subject: [Bug libstdc++/71660] [5/6/7/8 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86
- Auto-submitted: auto-generated
- References: <bug-71660-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71660
--- Comment #8 from Thiago Macieira <thiago at kde dot org> ---
(In reply to Peter Cordes from comment #7)
> 8B alignment is required for 8B objects to be efficiently lock-free (using
> SSE load / store for .load() and .store(), see
> https://stackoverflow.com/questions/36624881/why-is-integer-assignment-on-a-
> naturally-aligned-variable-atomic), and to avoid a factor of ~100 slowdown
> if lock cmpxchg8b is split across a cache-line boundary.
Unfortunately, the issue is not efficiency, but compatibility. The change broke
ABI for roughly 50% of structs containing atomic<64bit>. I understand being
fast, but not at the expense of silently breaking code at runtime.
> alignof(long double) in 32-bit is different from alignof(long double) in
> 64-bit. std::atomic<long double> or _Atomic long double should always have
> the same alignment as long double.
In and out of structs? That's the whole problem: inside structs, the alignment
is 4 for historical reasons.