<div dir="ltr">> <span style="font-size:12.8px">As I said, this is not a decision based on the libc++ version.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It is at least partially based on the libc++ version. We obviously can't enable the feature if libc++ does not yet support them.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">/Eric</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 30, 2016 at 2:00 PM, Joerg Sonnenberger via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Oct 30, 2016 at 01:49:53PM -0600, Eric Fiselier via cfe-commits wrote:<br>
> >  E.g. presence of libc++ won't tell you if you can use sized deallocation<br>
> > as that's a ABI library issue.<br>
><br>
>  The value of __libcpp_version could easily be updated by vendors to store<br>
> the version of the system dylib,<br>
> so I don't see why this wouldn't work.<br>
<br>
</span>As I said, this is not a decision based on the libc++ version. When we<br>
start adding random extra flags to the version file, it makes the point<br>
I'm raising even bigger: we are duplicating data and clang should not be<br>
magically changing its behavior like that anyway.<br>
<div class="HOEnZb"><div class="h5"><br>
Joerg<br>
______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div>