On Wed, May 22, 2013 at 3:01 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On May 22, 2013, at 2:49 AM, Stephan Tolksdorf <<a href="mailto:st@quanttec.com">st@quanttec.com</a>> wrote:<br>
> On 22.05.13 01:04, Howard Hinnant wrote:<br>
>> I recommend filing a bug against clang on this.  I am hesitant to commit the libc++ fix due to David Chisnall's concerns.  If the clang team reassigns the bug to libc++, then I will commit the libc++ solution.<br>

>><br>
><br>
> In case anyone has missed the previous reference to <a href="http://llvm.org/bugs/show_bug.cgi?id=16056" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=16056</a> and is considering a decision on how to proceed, I'd like to describe the consequence of that issue for the current _Atomic-based implementation of <atomic>:<br>

><br>
> If you initialize a static atomic variable with a constant expression (e.g. for some kind of lazy initialization scheme), your value is not constant initialized as expected but instead is dynamically initialized at program startup (because clang currently doesn't treat _Atomic(T) as a literal type). This may make your code vulnerable to the infamous "static initialization order fiasco", which can result in difficult to find bugs.<br>

<br>
</div>That seems fixable;  _Atomic(T) should be a literal type if T is.<br></blockquote><div><br></div><div>Agreed, and fixed in r182541.</div></div>