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

[Stephan Tolksdorf]

On 20.05.13 23:36, Howard Hinnant wrote:
> On May 20, 2013, at 5:20 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>> In late 2011 David Chisnall did the clang work to get <atomic> to work and updated <atomic> accordingly.  In Apr 2012 you switched <atomic> from __atomic_* builtins to __c11_atomic_* builtins.
>>
>> <shrug>  The libc++ <atomic> appears to work only for scalar types, and the C++11 spec says it should work for all trivially copyable types.  I know of no changes I can make to libc++ at this time to fix that.  Clang experts please advise.
>>
>> I think there are basically two long-term options and one short-term workaround:
>>
>> 1) Use T rather than _Atomic(T), manually ensure that std::atomic<T> has the right alignment, and use the __atomic_* builtins instead of the __c11_atomic_* builtins (this is the approach which libstdc++ takes), or
>> 2) Get someone to implement initialization support for _Atomic(T), where T is a class type where the selected copy/move constructor is trivial. I don't have time to work on this right now, I'm afraid.
>>
>> Workaround: Use __c11_atomic_init instead of initializing the member in the mem-initializer-list, for now at least. This has the disadvantage that you can't mark the constructor as 'constexpr', but you could restrict this to the case of non-scalar T to avoid regressing.
>
> Thanks.  Do we have any documentation for the __atomic_* builtins?
>

Switching to the __atomic builtins could also fix
http://llvm.org/bugs/show_bug.cgi?id=16056

The GCC builtins are currently documented here
http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/_005f_005fatomic-Builtins.html

- Stephan