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

[John McCall]

On May 21, 2013, at 6:11 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> On 21 May 2013, at 01:55, Howard Hinnant <hhinnant at apple.com> wrote:
>> I've enclosed a proposed patch for fixing <atomic>.  This patch changes us from using _Atomic(T) for the stored type, to just T, but aligned to _Atomic(T).  
> 
> This may still end up with the std::atomic<> types lacking padding in structures that makes it possible to act on them correctly.  For example, what do you get when you do:
> 
> struct {
> 	std::atomic<char> x;
> 	char y;
> };
> 
> y should be sufficiently after x that they can be operated on independently (at least from an ISA perspective - if they're in the same cache line then most RISCy CPUs will do a bit of redundant work anyway).  Even though the alignment of y is 1, we (typically) should be adding 3 bytes of padding after x.

In C, the size of a type will always be a multiple of its alignment.  If std::atomic<char> has alignment 4, its size is guaranteed to be a multiple of 4.  So changing the field from _Atomic(T) to T and then aligning it back up to alignof(_Atomic(T)) really achieves very little except for making the library deal with all the problems with size mismatches and uninitialized padding that the compiler already has support for.(as incomplete as that support may be).

It looks like libc++ puts std::atomic<T> in the libc++-specific namespace, so we don't really interoperate with libstdc++ here anyway.

Personally, I favor continuing to use _Atomic(T) as the implementation of std::atomic.  The two language proposals were intentionally aligned;  frankly, I feel that there's a tacit understanding that std::atomic<T> and _Atomic(T) will be compatible types in the C sense, but even if you don't accept that, it makes sense for them to share a common underlying implementation.  Among other things, that helps to ensure _Atomic is actually appropriately tested, at least inasmuch as std::atomic exploits it.

John.