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

[Richard Smith]

On Mon, May 20, 2013 at 3:36 PM, Stephan Tolksdorf <st at quanttec.com> wrote:

> 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<http://llvm.org/bugs/show_bug.cgi?id=16056>


Indeed it would! Though we should teach Clang to treat _Atomic(T) as a
literal type regardless.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130520/832bbedf/attachment.html>