[cfe-dev] libc++: help diagnosing the following std::atomic compile error

[David Chisnall]

On 20 May 2013, at 22:49, Richard Smith <richard at metafoo.co.uk> wrote:

> struct T { char c[3]; };
> static_assert(sizeof(std::atomic<T>) == 3 && alignof(std::atomic<T>) == 1, "under libstdc++");
> static_assert(sizeof(std::atomic<T>) == 4 && alignof(std::atomic<T>) == 4, "under libc++");

This looks like an ABI issue, but I don't imagine that we'll encounter any ABIs where the libstdc++ answer should be correct for alignof.  It's debatable whether the sizeof answer is correct, as the last byte should be padding, but as the intention of C11 _Atomic() and C++11 std::atomic<> is to be compiled down (for <word size types) to single atomic load / store operations (or short load-linked, store-conditional sequences) without exposing racy issues libstdc++ answer looks wrong (I know of no architectures which can do 3-byte atomic ops, and with alignof(1) this could end up spanning two cache lines and be impossible to operate on atomically without a mutex in anything except Haswell or BlueGene/Q).

This is my concern with the GCC atomic builtins, and why I am not happy with clang supporting them or encouraging their use.  There is explicitly no guarantee in C11 that T and _Atomic(T) have the same ABI and it was expected that they would not, because efficient atomic operations have stricter constraints (much stricter on some architectures, a bit stricter on x86).  It is almost impossible to use the GCC builtins correctly in a situation where the ABIs differ for the atomic and non-atomic types.

David