
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">My opinion:<div class=""><br class=""></div><div class="">Unstable ABI means unstable, period. No guarantees whatsoever except if you compile the program with the same toolchain and same flags (within reason -- warnings shouldn't impact the ABI). Keeping the ABI stable is so difficult that claiming anything more complex than "full ABI compat" or "no ABI compat at all" is naive IMO. We'll end up breaking it in subtle ways anyway.</div><div class=""><br class=""></div><div class="">So I'm OK with the proposed change in principle (but not about the details of how it's implemented, see the review for details).</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jun 26, 2019, at 18:09, James Y Knight via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I think autodetection of ABI-changing features is a bad idea, no matter in the stable or unstable ABI.<div class=""><br class=""></div><div class="">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></blockquote><div><br class=""></div><div>I agree, however with the tools we have today, I think that would mean encoding every single ABI-changing feature into an inline namespace. Then you'd get a link error instead of a runtime error.</div><div><br class=""></div><div>Louis</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""></div><div class=""><br class=""></div><div class="">That goes for both your cross-compiler and cross-language-version (and yes, we're getting the latter wrong already in the <i class="">stable</i> ABI now -- and should fix that!)</div><div class=""><br class=""></div><div class="">I also don't like the idea of the unstable ABI being incompatible with GCC. But, having the unstable ABI require a <i class="">new</i> version of GCC or Clang seems like a fine idea.</div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><br class=""></div><div class=""></div></div></div><div dir="auto" class=""><div class=""><br class=""><br class=""><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" class="">libcxx-dev@lists.llvm.org</a>> wrote:<br class=""></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" class="">Hi,<div class=""><br class=""></div><div class="">In <a href="https://reviews.llvm.org/D63744" rel="noreferrer" target="_blank" class="">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 class=""><br class=""></div><div class="">Do we think that's acceptable? Specifically:</div><div class=""><br class=""></div><div class=""> * Do users of the unstable ABI need it to be ABI-compatible across compiler versions and across compilers?</div><div class=""> * 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 class=""><br class=""></div><div class="">And (deep breath) would version-locking the unstable ABI to the corresponding version of Clang be acceptable?</div><div class=""><br class=""></div><div class="">Thanks!</div><div class="">Richard</div></div>

_______________________________________________<br class="">

libcxx-dev mailing list<br class="">

<a href="mailto:libcxx-dev@lists.llvm.org" rel="noreferrer" target="_blank" class="">libcxx-dev@lists.llvm.org</a><br class="">

<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br class="">

</blockquote></div></div></div>

_______________________________________________<br class="">libcxx-dev mailing list<br class=""><a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev<br class=""></div></blockquote></div><br class=""></body></html>