<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 4, 2014 at 5:19 AM, Marshall Clow <span dir="ltr"><<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">On Jun 3, 2014, at 2:28 PM, Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>> wrote:<br>
<div><br><blockquote type="cite"><div dir="ltr">Ping?</div></blockquote><div><br></div><div>Is there some reason that you’re using __SIZEOF_SIZE_T__ instead of sizeof(size_t) ?</div></div></div></blockquote><div><br></div>
<div>I believe sizeof can't be used in preprocessor lines (else the preprocessor would have to call into sema to get the size, and sema doesn't know about most types at preprocessing time yet.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Other than that, LGTM.<br></div></div></blockquote><div><br></div><div>r210188, thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div></div><span class=""><font color="#888888"><div><br></div><div>— Marshall</div></font></span><div><div class="h5"><div><br><blockquote type="cite"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jun 2, 2014 at 10:11 AM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Ping.</div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">
On Fri, May 30, 2014 at 4:04 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>on trunk, libc++ relies on undefined initialization order of global initializers when using gcc:</div>
<div><br></div><div>1. __start_std_streams in iostream.cpp calls locale::id::_init, which assigns an id to each locale::facet in an initializer</div>
<div><br></div><div>2. Every facet has a static locale::id id, whose constructor sets the facet's id to 0*</div><div><br></div><div>If 2 runs after 1, it clobbers the facet's assigned consecutive id, causing exceptions to be thrown when e.g. running code like "cout << endl".</div>
<div><br></div><div>To fix this, the attached patch lets _LIBCPP_CONSTEXPR evaluate to "constexpr" instead of nothing with gcc. locale::id's constructor is marked _LIBCPP_CONSTEXPR, which ensures that it won't get an initializer that could potentially run after the iostream.cpp initializer. (This remains broken when building with msvc.)</div>
<div><br></div><div>Once _LIBCPP_CONSTEXPR is available, bitset fails to compile since gcc doesn't define __SIZE_WIDTH__, so switch bitset to use __SIZEOF_SIZE_T__ which both clang and gcc define.</div><div><br></div>
<div>Pair-programmed/debugged with Dana Jansens.</div><span><font color="#888888"><div><br></div><div>Nico</div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div></div>