[libcxx-dev] unstable ABI compiler assumptions

Eric Fiselier via libcxx-dev libcxx-dev at lists.llvm.org
Tue Jun 25 23:14:50 PDT 2019

I suspect users of the unstable ABI compile almost everything with the same
(They must compile almost everything from source)

I think providing a version-locked super-unstable ABI is fine so long as
libc++ still maintains a
distinction between features that are inherently unstable, and stable
features in unstable for staging.
One day we might actually be in a position to release ABI v2 and deprecate
ABI v1.

In general, I believe libc++ would benefit from tighter version-locking.
Having to wait 5 years for
a feature to trickle down into the minimum supported compilers doesn't help
libc++ or its users.

On Mon, Jun 24, 2019 at 7:28 PM Richard Smith via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

> Hi,
> In 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
> 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/20190626/bf57f60c/attachment.html>

More information about the libcxx-dev mailing list