[cfe-dev] libc++: help diagnosing the following std::atomic compile error
richard at metafoo.co.uk
Mon May 20 15:52:52 PDT 2013
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
>>> 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
Indeed it would! Though we should teach Clang to treat _Atomic(T) as a
literal type regardless.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev