[libcxx-dev] unstable ABI compiler assumptions

Thu Jun 27 10:32:29 PDT 2019

My opinion:

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.

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).

> On Jun 26, 2019, at 18:09, James Y Knight via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> I think autodetection of ABI-changing features is a bad idea, no matter in the stable or unstable ABI.
> 
> 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.

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.

Louis

> 
> That goes for both your cross-compiler and cross-language-version (and yes, we're getting the latter wrong already in the stable ABI now -- and should fix that!)
> 
> I also don't like the idea of the unstable ABI being incompatible with GCC. But, having the unstable ABI require a new version of GCC or Clang seems like a fine idea.
> 
> 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).
> 
> 
> 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.
> 
> 
> 
> 
> On Mon, Jun 24, 2019, 7:28 PM Richard Smith via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
> Hi,
> 
> In https://reviews.llvm.org/D63744 <https://reviews.llvm.org/D63744> 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).
> 
> Do we think that's acceptable? Specifically:
> 
>  * Do users of the unstable ABI need it to be ABI-compatible across compiler versions and across compilers?
>  * Do users of the unstable ABI need it to be ABI-compatible across C++ language modes (in particular, C++98 versus everything else)?
> 
> And (deep breath) would version-locking the unstable ABI to the corresponding version of Clang be acceptable?
> 
> Thanks!
> Richard
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190627/1da920ba/attachment.html>