llvm dev - Mar 2021 - Compiler support in libc++

Dear LLVM community,

I’ve wanted to address the topic of which compilers are supported by libc++
for a long time. LLVM documents that it supports GCC >= 5, Clang >= 3.5
and
other fairly old compilers. I think this makes a lot of sense for codebases
like LLVM and Clang, since it means you can bootstrap a compiler with your
system compiler in many cases. It’s also fairly easy to enforce that, since
you just have to code in a supported subset of C++.

However, for a library like libc++, things are a bit different. By its very
nature, libc++ needs to rely on a recent compiler in order to implement
most recent library features. Not being able to rely on a recent compiler
leads to problems:

   -

   Adding new features is significantly more complicated because we need to
   implement them conditionally on compiler support, not just on support for a
   C++ Standard. There can also be interactions between what compiler the
   library is built with and what compiler the headers are used with.
   -

   We accumulate technical debt around the code base. Some of these #ifdef
   code paths are not in use anymore, others don’t compile anymore or they
   contain bugs.
   -

   It creates a false sense of support: people think they can use a libc++
   built with e.g. Clang 3.5, but in reality doing so is a terrible idea. The
   library might not contain runtime support for features that will be
   advertised as available by the headers (the char8_t RTTI and the upcoming
   support for <format> come to mind). Those are serious ABI issues that
   you’ll only notice when trying to use the feature.


I think it’s important to stress that the current state of things is that
we don’t *actually* support much older compilers - the documentation claims
we do, but that is misleading. While things may happen to work on older
compilers, I wouldn’t recommend relying on that for anything serious, since
it’s mostly untested.

Furthermore, the actual value of supporting old compilers isn’t obvious.
Indeed, the best way of building libc++ is to bootstrap Clang and then
build libc++ with it, which is easily achieved with the LLVM Runtimes
build. Of course, we also support different shipping mechanisms (including
non-Clang compilers), but in all cases it should be reasonable to expect
that someone building libc++ at the tip is able to do so using a recent
compiler.

For all these reasons, I think we must adjust the official support policy
we currently document. Concretely, the following modified policy solves the
issues I mentioned above and makes it so that the stated support reflects
the reality of what we truly support:

   -

   At any given point in time, libc++ supports back to the latest released
   version of Clang. For example, if the latest major release of Clang is 14,
   libc++ (on main) supports Clang 14. When Clang 15 is released (and libc++
   15 with it), libc++ (on main) is free to assume Clang 15. As a result, any
   released libc++ will always support the previously (and the currently)
   released Clang, with the support window moving as newer Clangs are released.
   -

   We support the latest major release of GCC, as advertised on
   https://gcc.gnu.org/releases.html.
   -

   We support the latest major release of AppleClang.


The above policy is reasonable from libc++’s perspective, and it also
reflects what we test on a regular basis with the CI. Furthermore,
supporting up to the last release instead of requiring a trunk compiler
(like MSVC’s STL and libstdc++) gives vendors with alternate delivery
vehicles approximately 6 months to update their compiler if they want to
jump on the next release of libc++, which I think is an important property
to retain.

This message is both a heads up about the current state of things, an
explanation of where we (the libc++ contributors) want to end up, and an
invitation to have a discussion with the rest of the community.

I propose that we maintain our current level of support for older compilers
(i.e. keep things roughly building) until the next LLVM release, after
which the above policy would become official and libc++ development would
be allowed to assume a compiler as documented above. That would give
approximately 6 months (from now to the next release) for people managing
build bots to migrate to the Runtimes build, and approximately 6 months
(from the next release to the next-next release) for external users to
adjust to this policy if needed.

Thanks,

Louis

P.S.: There is no mention of other compilers besides Clang, AppleClang and
GCC above. That’s because no other compiler is tested on a regular basis,
so the status of support for other compilers is unknown. If you’d like to
add official support for a new compiler, I’ll be happy to help you set up
the required testing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210301/3bd8f2b4/attachment.html>

As a libc++ contributor a +1

Cheers,
Mark de Wever

On Mon, Mar 01, 2021 at 12:40:36PM -0500, Louis Dionne via llvm-dev
wrote:
> Dear LLVM community,
> 
> I’ve wanted to address the topic of which compilers are supported by libc++
> for a long time. LLVM documents that it supports GCC >= 5, Clang >=
3.5 and
> other fairly old compilers. I think this makes a lot of sense for codebases
> like LLVM and Clang, since it means you can bootstrap a compiler with your
> system compiler in many cases. It’s also fairly easy to enforce that, since
> you just have to code in a supported subset of C++.
> 
> However, for a library like libc++, things are a bit different. By its very
> nature, libc++ needs to rely on a recent compiler in order to implement
> most recent library features. Not being able to rely on a recent compiler
> leads to problems:
> 
>    -
> 
>    Adding new features is significantly more complicated because we need to
>    implement them conditionally on compiler support, not just on support
for a
>    C++ Standard. There can also be interactions between what compiler the
>    library is built with and what compiler the headers are used with.
>    -
> 
>    We accumulate technical debt around the code base. Some of these #ifdef
>    code paths are not in use anymore, others don’t compile anymore or they
>    contain bugs.
>    -
> 
>    It creates a false sense of support: people think they can use a libc++
>    built with e.g. Clang 3.5, but in reality doing so is a terrible idea.
The
>    library might not contain runtime support for features that will be
>    advertised as available by the headers (the char8_t RTTI and the
upcoming
>    support for <format> come to mind). Those are serious ABI issues
that
>    you’ll only notice when trying to use the feature.
> 
> 
> I think it’s important to stress that the current state of things is that
> we don’t *actually* support much older compilers - the documentation claims
> we do, but that is misleading. While things may happen to work on older
> compilers, I wouldn’t recommend relying on that for anything serious, since
> it’s mostly untested.
> 
> Furthermore, the actual value of supporting old compilers isn’t obvious.
> Indeed, the best way of building libc++ is to bootstrap Clang and then
> build libc++ with it, which is easily achieved with the LLVM Runtimes
> build. Of course, we also support different shipping mechanisms (including
> non-Clang compilers), but in all cases it should be reasonable to expect
> that someone building libc++ at the tip is able to do so using a recent
> compiler.
> 
> For all these reasons, I think we must adjust the official support policy
> we currently document. Concretely, the following modified policy solves the
> issues I mentioned above and makes it so that the stated support reflects
> the reality of what we truly support:
> 
>    -
> 
>    At any given point in time, libc++ supports back to the latest released
>    version of Clang. For example, if the latest major release of Clang is
14,
>    libc++ (on main) supports Clang 14. When Clang 15 is released (and
libc++
>    15 with it), libc++ (on main) is free to assume Clang 15. As a result,
any
>    released libc++ will always support the previously (and the currently)
>    released Clang, with the support window moving as newer Clangs are
released.
>    -
> 
>    We support the latest major release of GCC, as advertised on
>    https://gcc.gnu.org/releases.html.
>    -
> 
>    We support the latest major release of AppleClang.
> 
> 
> The above policy is reasonable from libc++’s perspective, and it also
> reflects what we test on a regular basis with the CI. Furthermore,
> supporting up to the last release instead of requiring a trunk compiler
> (like MSVC’s STL and libstdc++) gives vendors with alternate delivery
> vehicles approximately 6 months to update their compiler if they want to
> jump on the next release of libc++, which I think is an important property
> to retain.
> 
> This message is both a heads up about the current state of things, an
> explanation of where we (the libc++ contributors) want to end up, and an
> invitation to have a discussion with the rest of the community.
> 
> I propose that we maintain our current level of support for older compilers
> (i.e. keep things roughly building) until the next LLVM release, after
> which the above policy would become official and libc++ development would
> be allowed to assume a compiler as documented above. That would give
> approximately 6 months (from now to the next release) for people managing
> build bots to migrate to the Runtimes build, and approximately 6 months
> (from the next release to the next-next release) for external users to
> adjust to this policy if needed.
> 
> Thanks,
> 
> Louis
> 
> P.S.: There is no mention of other compilers besides Clang, AppleClang and
> GCC above. That’s because no other compiler is tested on a regular basis,
> so the status of support for other compilers is unknown. If you’d like to
> add official support for a new compiler, I’ll be happy to help you set up
> the required testing.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

As a (rare) stl contributor I am also strongly in favor of the proposal.

I greatly reduces the maintenance burden for us.

--Michael

Am Mo., 1. März 2021 um 18:40 Uhr schrieb Louis Dionne via libcxx-dev <
libcxx-dev at lists.llvm.org>:
> Dear LLVM community,
>
> I’ve wanted to address the topic of which compilers are supported by
> libc++ for a long time. LLVM documents that it supports GCC >= 5, Clang
>> 3.5 and other fairly old compilers. I think this makes a lot of sense
for
> codebases like LLVM and Clang, since it means you can bootstrap a compiler
> with your system compiler in many cases. It’s also fairly easy to enforce
> that, since you just have to code in a supported subset of C++.
>
> However, for a library like libc++, things are a bit different. By its
> very nature, libc++ needs to rely on a recent compiler in order to
> implement most recent library features. Not being able to rely on a recent
> compiler leads to problems:
>
>    -
>
>    Adding new features is significantly more complicated because we need
>    to implement them conditionally on compiler support, not just on support
>    for a C++ Standard. There can also be interactions between what compiler
>    the library is built with and what compiler the headers are used with.
>    -
>
>    We accumulate technical debt around the code base. Some of these
>    #ifdef code paths are not in use anymore, others don’t compile anymore
or
>    they contain bugs.
>    -
>
>    It creates a false sense of support: people think they can use a
>    libc++ built with e.g. Clang 3.5, but in reality doing so is a terrible
>    idea. The library might not contain runtime support for features that
will
>    be advertised as available by the headers (the char8_t RTTI and the
>    upcoming support for <format> come to mind). Those are serious ABI
issues
>    that you’ll only notice when trying to use the feature.
>
>
> I think it’s important to stress that the current state of things is that
> we don’t *actually* support much older compilers - the documentation claims
> we do, but that is misleading. While things may happen to work on older
> compilers, I wouldn’t recommend relying on that for anything serious, since
> it’s mostly untested.
>
> Furthermore, the actual value of supporting old compilers isn’t obvious.
> Indeed, the best way of building libc++ is to bootstrap Clang and then
> build libc++ with it, which is easily achieved with the LLVM Runtimes
> build. Of course, we also support different shipping mechanisms (including
> non-Clang compilers), but in all cases it should be reasonable to expect
> that someone building libc++ at the tip is able to do so using a recent
> compiler.
>
> For all these reasons, I think we must adjust the official support policy
> we currently document. Concretely, the following modified policy solves the
> issues I mentioned above and makes it so that the stated support reflects
> the reality of what we truly support:
>
>    -
>
>    At any given point in time, libc++ supports back to the latest
>    released version of Clang. For example, if the latest major release of
>    Clang is 14, libc++ (on main) supports Clang 14. When Clang 15 is
released
>    (and libc++ 15 with it), libc++ (on main) is free to assume Clang 15. As
a
>    result, any released libc++ will always support the previously (and the
>    currently) released Clang, with the support window moving as newer
Clangs
>    are released.
>    -
>
>    We support the latest major release of GCC, as advertised on
>    https://gcc.gnu.org/releases.html.
>    -
>
>    We support the latest major release of AppleClang.
>
>
> The above policy is reasonable from libc++’s perspective, and it also
> reflects what we test on a regular basis with the CI. Furthermore,
> supporting up to the last release instead of requiring a trunk compiler
> (like MSVC’s STL and libstdc++) gives vendors with alternate delivery
> vehicles approximately 6 months to update their compiler if they want to
> jump on the next release of libc++, which I think is an important property
> to retain.
>
> This message is both a heads up about the current state of things, an
> explanation of where we (the libc++ contributors) want to end up, and an
> invitation to have a discussion with the rest of the community.
>
> I propose that we maintain our current level of support for older
> compilers (i.e. keep things roughly building) until the next LLVM release,
> after which the above policy would become official and libc++ development
> would be allowed to assume a compiler as documented above. That would give
> approximately 6 months (from now to the next release) for people managing
> build bots to migrate to the Runtimes build, and approximately 6 months
> (from the next release to the next-next release) for external users to
> adjust to this policy if needed.
>
> Thanks,
>
> Louis
>
> P.S.: There is no mention of other compilers besides Clang, AppleClang and
> GCC above. That’s because no other compiler is tested on a regular basis,
> so the status of support for other compilers is unknown. If you’d like to
> add official support for a new compiler, I’ll be happy to help you set up
> the required testing.
>
> _______________________________________________
> 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/llvm-dev/attachments/20210301/bdefbe2c/attachment.html>

On Mon, Mar 01, 2021 at 12:40:36PM -0500, Louis Dionne via llvm-dev
wrote:
> However, for a library like libc++, things are a bit different.
So how does this prevent the libstdc++ mess that you need to lock step
the RTL with the compiler and more importantly, get constantly screwed
over when you need to upgrade or downgrade the compiler in a complex
environment like an actual Operating System?

I consider this proposal a major step backwards...

Joerg

As a libc++ contributor, I am strongly in favor of this. I'd like to
re-iterate three main points:

   1. Currently, we are telling users that libc++ supports Clang 3.5 (for
   example) when there is no proof of that. We are basically guessing
   (actually, we're not even guessing; if I had to guess, I'd say that
Clang
   3.5 probably won't work).
   2. This will make the QoI way better. Bugs are hidden in macros when we
   have to support many/old compilers. We can also remove a lot of dead code,
   which will make it easier to reason about the implementation logic.
   3. Users of old compilers can download old versions of libc++ (in the
   uncommon case when this is required) by simply heading to
   https://releases.llvm.org/download.html.


Thanks for pushing this forward, Louis!

On Mon, Mar 1, 2021 at 9:40 AM Louis Dionne via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:
> Dear LLVM community,
>
> I’ve wanted to address the topic of which compilers are supported by
> libc++ for a long time. LLVM documents that it supports GCC >= 5, Clang
>> 3.5 and other fairly old compilers. I think this makes a lot of sense
for
> codebases like LLVM and Clang, since it means you can bootstrap a compiler
> with your system compiler in many cases. It’s also fairly easy to enforce
> that, since you just have to code in a supported subset of C++.
>
> However, for a library like libc++, things are a bit different. By its
> very nature, libc++ needs to rely on a recent compiler in order to
> implement most recent library features. Not being able to rely on a recent
> compiler leads to problems:
>
>    -
>
>    Adding new features is significantly more complicated because we need
>    to implement them conditionally on compiler support, not just on support
>    for a C++ Standard. There can also be interactions between what compiler
>    the library is built with and what compiler the headers are used with.
>    -
>
>    We accumulate technical debt around the code base. Some of these
>    #ifdef code paths are not in use anymore, others don’t compile anymore
or
>    they contain bugs.
>    -
>
>    It creates a false sense of support: people think they can use a
>    libc++ built with e.g. Clang 3.5, but in reality doing so is a terrible
>    idea. The library might not contain runtime support for features that
will
>    be advertised as available by the headers (the char8_t RTTI and the
>    upcoming support for <format> come to mind). Those are serious ABI
issues
>    that you’ll only notice when trying to use the feature.
>
>
> I think it’s important to stress that the current state of things is that
> we don’t *actually* support much older compilers - the documentation claims
> we do, but that is misleading. While things may happen to work on older
> compilers, I wouldn’t recommend relying on that for anything serious, since
> it’s mostly untested.
>
> Furthermore, the actual value of supporting old compilers isn’t obvious.
> Indeed, the best way of building libc++ is to bootstrap Clang and then
> build libc++ with it, which is easily achieved with the LLVM Runtimes
> build. Of course, we also support different shipping mechanisms (including
> non-Clang compilers), but in all cases it should be reasonable to expect
> that someone building libc++ at the tip is able to do so using a recent
> compiler.
>
> For all these reasons, I think we must adjust the official support policy
> we currently document. Concretely, the following modified policy solves the
> issues I mentioned above and makes it so that the stated support reflects
> the reality of what we truly support:
>
>    -
>
>    At any given point in time, libc++ supports back to the latest
>    released version of Clang. For example, if the latest major release of
>    Clang is 14, libc++ (on main) supports Clang 14. When Clang 15 is
released
>    (and libc++ 15 with it), libc++ (on main) is free to assume Clang 15. As
a
>    result, any released libc++ will always support the previously (and the
>    currently) released Clang, with the support window moving as newer
Clangs
>    are released.
>    -
>
>    We support the latest major release of GCC, as advertised on
>    https://gcc.gnu.org/releases.html.
>    -
>
>    We support the latest major release of AppleClang.
>
>
> The above policy is reasonable from libc++’s perspective, and it also
> reflects what we test on a regular basis with the CI. Furthermore,
> supporting up to the last release instead of requiring a trunk compiler
> (like MSVC’s STL and libstdc++) gives vendors with alternate delivery
> vehicles approximately 6 months to update their compiler if they want to
> jump on the next release of libc++, which I think is an important property
> to retain.
>
> This message is both a heads up about the current state of things, an
> explanation of where we (the libc++ contributors) want to end up, and an
> invitation to have a discussion with the rest of the community.
>
> I propose that we maintain our current level of support for older
> compilers (i.e. keep things roughly building) until the next LLVM release,
> after which the above policy would become official and libc++ development
> would be allowed to assume a compiler as documented above. That would give
> approximately 6 months (from now to the next release) for people managing
> build bots to migrate to the Runtimes build, and approximately 6 months
> (from the next release to the next-next release) for external users to
> adjust to this policy if needed.
>
> Thanks,
>
> Louis
>
> P.S.: There is no mention of other compilers besides Clang, AppleClang and
> GCC above. That’s because no other compiler is tested on a regular basis,
> so the status of support for other compilers is unknown. If you’d like to
> add official support for a new compiler, I’ll be happy to help you set up
> the required testing.
>
> _______________________________________________
> 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/llvm-dev/attachments/20210301/1b1262b6/attachment.html>

I think it's reasonable to raise the compiler version floor for libc++, but
I think I would like to see a more relaxed policy with respect to clang.
Maybe the last two releases of clang, so that a user of ToT libc++ with
stable clang doesn't have to rush to upgrade clang as soon as it is
released. If you support the last two releases, the user always has six
months of lead time before updating, and libc++ never supports a compiler
older than a year.

I'll also point out that, I see a lot of support on this thread, but I see
a lot of developer representation, and not much user representation. I have
no idea how to effectively survey users of libc++, though.

Lastly, from Chromium's PoV, Chromium has an ancient NaCl toolchain, and we
believe we may be using ToT libc++ with it. We have other reasons (C++17
for one) to want to either remove or update this compiler, so please don't
consider this a blocker for libc++. I only mention it to show that users do
sometimes inadvertently develop dependencies on old compilers.

On Mon, Mar 1, 2021 at 9:41 AM Louis Dionne via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Dear LLVM community,
>
> I’ve wanted to address the topic of which compilers are supported by
> libc++ for a long time. LLVM documents that it supports GCC >= 5, Clang
>> 3.5 and other fairly old compilers. I think this makes a lot of sense
for
> codebases like LLVM and Clang, since it means you can bootstrap a compiler
> with your system compiler in many cases. It’s also fairly easy to enforce
> that, since you just have to code in a supported subset of C++.
>
> However, for a library like libc++, things are a bit different. By its
> very nature, libc++ needs to rely on a recent compiler in order to
> implement most recent library features. Not being able to rely on a recent
> compiler leads to problems:
>
>    -
>
>    Adding new features is significantly more complicated because we need
>    to implement them conditionally on compiler support, not just on support
>    for a C++ Standard. There can also be interactions between what compiler
>    the library is built with and what compiler the headers are used with.
>    -
>
>    We accumulate technical debt around the code base. Some of these
>    #ifdef code paths are not in use anymore, others don’t compile anymore
or
>    they contain bugs.
>    -
>
>    It creates a false sense of support: people think they can use a
>    libc++ built with e.g. Clang 3.5, but in reality doing so is a terrible
>    idea. The library might not contain runtime support for features that
will
>    be advertised as available by the headers (the char8_t RTTI and the
>    upcoming support for <format> come to mind). Those are serious ABI
issues
>    that you’ll only notice when trying to use the feature.
>
>
> I think it’s important to stress that the current state of things is that
> we don’t *actually* support much older compilers - the documentation claims
> we do, but that is misleading. While things may happen to work on older
> compilers, I wouldn’t recommend relying on that for anything serious, since
> it’s mostly untested.
>
> Furthermore, the actual value of supporting old compilers isn’t obvious.
> Indeed, the best way of building libc++ is to bootstrap Clang and then
> build libc++ with it, which is easily achieved with the LLVM Runtimes
> build. Of course, we also support different shipping mechanisms (including
> non-Clang compilers), but in all cases it should be reasonable to expect
> that someone building libc++ at the tip is able to do so using a recent
> compiler.
>
> For all these reasons, I think we must adjust the official support policy
> we currently document. Concretely, the following modified policy solves the
> issues I mentioned above and makes it so that the stated support reflects
> the reality of what we truly support:
>
>    -
>
>    At any given point in time, libc++ supports back to the latest
>    released version of Clang. For example, if the latest major release of
>    Clang is 14, libc++ (on main) supports Clang 14. When Clang 15 is
released
>    (and libc++ 15 with it), libc++ (on main) is free to assume Clang 15. As
a
>    result, any released libc++ will always support the previously (and the
>    currently) released Clang, with the support window moving as newer
Clangs
>    are released.
>    -
>
>    We support the latest major release of GCC, as advertised on
>    https://gcc.gnu.org/releases.html.
>    -
>
>    We support the latest major release of AppleClang.
>
>
> The above policy is reasonable from libc++’s perspective, and it also
> reflects what we test on a regular basis with the CI. Furthermore,
> supporting up to the last release instead of requiring a trunk compiler
> (like MSVC’s STL and libstdc++) gives vendors with alternate delivery
> vehicles approximately 6 months to update their compiler if they want to
> jump on the next release of libc++, which I think is an important property
> to retain.
>
> This message is both a heads up about the current state of things, an
> explanation of where we (the libc++ contributors) want to end up, and an
> invitation to have a discussion with the rest of the community.
>
> I propose that we maintain our current level of support for older
> compilers (i.e. keep things roughly building) until the next LLVM release,
> after which the above policy would become official and libc++ development
> would be allowed to assume a compiler as documented above. That would give
> approximately 6 months (from now to the next release) for people managing
> build bots to migrate to the Runtimes build, and approximately 6 months
> (from the next release to the next-next release) for external users to
> adjust to this policy if needed.
>
> Thanks,
>
> Louis
>
> P.S.: There is no mention of other compilers besides Clang, AppleClang and
> GCC above. That’s because no other compiler is tested on a regular basis,
> so the status of support for other compilers is unknown. If you’d like to
> add official support for a new compiler, I’ll be happy to help you set up
> the required testing.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210308/a6da63ee/attachment.html>