[libcxx-commits] [PATCH] D126462: [libc++] Re-enable std::pair trivial copy constructor for FreeBSD >= 14

Louis Dionne via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Fri Jun 3 07:15:33 PDT 2022

ldionne accepted this revision.
ldionne added a comment.

The change itself LGTM.

Stabilizing ABI v2 raises some interesting questions. For example, if we stabilize ABI v2, does it mean that we consider ABI v1 as "deprecated"? Do we start doing all development on ABI v2 by default and keep around one (or several) CI jobs to continue testing ABI v1? Do we start building ABI v2 by default when someone configures libc++? What ABI version do we ship in the LLVM release?

Concretely, if we deprecate ABI v1, we'll put everyone who require ABI stability in a situation where they are using a deprecated thing. Unless there is a rather serious effort from those folks (I include myself here) to move off of ABI v1, there is basically no timeline for moving off, which means that we'd have introduced a deprecation situation with no real horizon for getting out of it. So far, our ABI flags have been treated as just knobs -- basically you cherry-pick the ABI changes you want when you introduce a new target, and that's what defines your ABI on that target. You then keep the same ABI until that target is end-of-lifed, which may often be not-in-the-foreseeable-future.

So while I do support migrating to a newer ABI in principle, I think the discussion needs to happen a bit more widely in the LLVM community. I think it should be a common library + compiler effort, and we should design some sort of plan for how we're going to push vendors over to the new ABI over a course of X years, and then remove support for the old ABI. Note that X can be a large number of years, but it has to be finite, otherwise we'll just create problems for ourselves by adding one axis in the configuration space that we need to support in libc++.

I'm interested to hear what others think about this.

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list