
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div dir="ltr">On Jun 27, 2019, at 14:26, James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>On Thu, Jun 27, 2019 at 1:32 PM Louis Dionne <<a href="mailto:ldionne@apple.com">ldionne@apple.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">My opinion:<div><br></div><div>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></blockquote><div><br></div><div>IMO, the unstable ABI ought to be managed in such a way as to make it suitable to convert into an ABIv2 at some point in the future. So, it should have "full ABI compatibility" just like the stable ABI -- but unlike the stable ABI, only at a particular snapshot of the headers, not stable across all versions.</div><div><br></div><div>(IOW, a person may change the unstable ABI at any time by editing the header files, but with a particular snapshot of the headers, the abi-stability properties ought to be equivalent)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div></div><div>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><br></div><div><blockquote type="cite"><div>On Jun 26, 2019, at 18:09, James Y Knight via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-9222278839890224373Apple-interchange-newline"><div><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></blockquote><div><br></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></div></blockquote><div><br></div><div>That's not what I was going for at all. I think it's totally reasonable for it to be up to users of the unstable ABI to not mix-and-match objects compiled against different versions of the header files -- or else to manage their own custom namespace to avoid such conflicts. All I'm saying is that ABI-changing features ought to be enabled and disabled by editing the __config header file, not by auto-detecting what compiler is used to compile a particular source file.</div><div><br></div><div>That is, something like this:<br></div><div><br></div><div>[snip]</div></div></div></div></blockquote><div><br></div><div>Ah, I see what you were going for now. I like this approach better than the current one too. However, I still think it’s okay if the unstable ABI is unstable across compilers.</div><div><br></div><div>The unstable ABI is different from ABI v2. That ABI is unstable but it will eventually be stabilized (and hopefully replace ABI v1), and as a candidate for stabilization it should be stable across compilers and most compiler flags too. LIBCPP_ABI_UNSTABLE denotes that you don’t care about any ABI stability, and as such I think it’s okay for it to provide no guarantees whatsoever.</div><div><br></div><div>Does that make sense? I may be misunderstanding the initial intent of those macros, in which case someone please correct me. The documentation we currently have for the ABI macros doesn’t seem to clearly explain the intent for what we’re talking about.</div><div><br></div><div>Louis</div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div><div><div></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div>Louis</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br><blockquote type="cite"><div><div dir="ltr"><div><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>

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

</div></blockquote></body></html>