This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]