<div dir="ltr">I think autodetection of ABI-changing features is a bad idea, no matter in the stable or unstable ABI.<div><br></div><div>If libc++ wants to have an ABI which depends on certain new features from the compiler, that seems fine. But, when that ABI is enabled, trying to use the library with a compiler missing said feature should cause a compilation failure, not the silent use of an incompatible ABI.<div></div><div><br></div><div>That goes for both your cross-compiler and cross-language-version (and yes, we're getting the latter wrong already in the <i>stable</i> ABI now -- and should fix that!)</div><div><br></div><div>I also don't like the idea of the unstable ABI being incompatible with GCC. But, having the unstable ABI require a <i>new</i> version of GCC or Clang seems like a fine idea.</div><div><br></div><div>So, concretely, I'd say that it should be fine to require support for no_unique_address in libc++'s unstable ABI (that's not clang-specific -- and both GCC and Clang have implemented it).<br></div><div><br></div><div><br></div><div>That said, I also wonder -- why must switching to no_unique_address change the ABI at all? Doesn't the way it was implemented mean that it's actually layout compatible to switch EBCO uses over to using no_unique_address? It'd sure be nice if no_unique_address could be used without ABI breakage when it's supported, even in the stable v1 ABI.</div><div><br></div><div><br></div><div></div></div></div><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 24, 2019, 7:28 PM Richard Smith via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>In <a href="https://reviews.llvm.org/D63744" rel="noreferrer" target="_blank">https://reviews.llvm.org/D63744</a> I'm proposing a change to libc++ that (unless we add an additional configuration flag) would mean that the unstable ABI is not necessarily ABI-compatible with itself across different compilers (in particular, one that supports a particular C++ attribute and one that does not), nor between C++ language modes that support that attribute and those that don't (which in both Clang and GCC is C++98/03 versus everything else).</div><div><br></div><div>Do we think that's acceptable? Specifically:</div><div><br></div><div> * Do users of the unstable ABI need it to be ABI-compatible across compiler versions and across compilers?</div><div> * Do users of the unstable ABI need it to be ABI-compatible across C++ language modes (in particular, C++98 versus everything else)?</div><div><br></div><div>And (deep breath) would version-locking the unstable ABI to the corresponding version of Clang be acceptable?</div><div><br></div><div>Thanks!</div><div>Richard</div></div>
_______________________________________________<br>
libcxx-dev mailing list<br>
<a href="mailto:libcxx-dev@lists.llvm.org" rel="noreferrer" target="_blank">libcxx-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br>
</blockquote></div></div></div>