[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
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:
> 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?
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libcxx-dev