1

TLDR: I’d like to codify that contributions to make LLVM usable with all published C++ version should be welcome. This is not related to changing the minimum version requirement of C++17.

It came out recently that some downstream projects were using more recent version of C++ than what are using to build LLVM at the moment. Someone wasn’t sure if contributions to help with this would be welcome.
I can’t find a clear policy on our support for more recent version of the standard. We document the minimum C++ version (mostly driven by the minimum toolchains we want to support) to build LLVM, however we’re lacking on an upper bound (if any).

There is precedent though, we setup a c++20 bot when the standard became available:

There are two cases:

  1. The C++ standard used to build LLVM itself. We document this in our CMake doc with the -DCMAKE_CXX_STANDARD option, where we mention “Possible values are 17 and 20”, even though there are no checks for this (I suspect it’s just that the doc was updated when C++20 came out). The doc also says “LLVM requires C++17 or higher”.

  2. The C++ standard that our customer can use (which impacts our public headers). I don’t find any documentation for this.

Since the project aims to upgrade “at some point” to newer version of the standard, I think we should support them as they come out, and accept patches to support C++23 as well as bots that would be configured in this mode.

One things of debate is that the support for newer C++ version can be imperfect across toolchains, and there is a risk of having to chase various bugs too early.
To address this we could reduce our support to say that we are limiting the support of newer version of the C++ standard to only the latest available versions of the compilers. That is today we would accept C++23 patches aimed at fixing incompatibilities in the codebase that are affecting clang-20, gcc-14.3, Visual Studio 2022 v17.14.

Here is a possible patch:

diff --git a/llvm/docs/CMake.rst b/llvm/docs/CMake.rst
index 30b71bffaf76..ed1f63e17a02 100644
--- a/llvm/docs/CMake.rst
+++ b/llvm/docs/CMake.rst
@@ -280,8 +280,8 @@ explanation and LLVM-related notes.  For full documentation, consult the CMake
 manual, or execute ``cmake --help-variable VARIABLE_NAME``.
 
 **CMAKE_CXX_STANDARD**:STRING
-  Sets the C++ standard to conform to when building LLVM.  Possible values are
-  17 and 20.  LLVM requires C++17 or higher.  This defaults to 17.
+  Sets the C++ standard to conform to when building LLVM.
+  LLVM requires C++17 or higher.  This defaults to 17.
 
 **CMAKE_INSTALL_BINDIR**:PATH
   The path to install executables, relative to the *CMAKE_INSTALL_PREFIX*.
diff --git a/llvm/docs/CodingStandards.rst b/llvm/docs/CodingStandards.rst
index e48af0ee3054..9ff6e0d14c22 100644
--- a/llvm/docs/CodingStandards.rst
+++ b/llvm/docs/CodingStandards.rst
@@ -78,6 +78,10 @@ Each toolchain provides a good reference for what it accepts:
 Additionally, there are compiler comparison tables of supported C++ features on
 `cppreference.com <https://en.cppreference.com/w/cpp/compiler_support/17>`_.
 
+To keep track with the evolution of the standard, newer C++ version can be used
+to build LLVM. However for version more recent than C++ we only provide support
+for the latest version of the supported toolchains.
+
 
 C++ Standard Library
 --------------------
8 Likes
2

This sounds reasonable to me.

Funnily, I merged the PR for C++23 support ([llvm] Support building with c++23 by kykrueger · Pull Request #154372 · llvm/llvm-project · GitHub) just before you put up this thread, as I assumed supporting newer standards versions is uncontroversial.

1 Like
3

Seems like a good clarification! +1 from me

4

In theory I think this makes sense.

My concern is that sitting in the WG21 Core Working Group, I see that we do have a growing number of core issues in which implementation diverge on, we can see a snapshot of this by looking at the diverges-from label. So by expanding the number of versions we sanction for folks to build with we are opening us up to a growing number of these sorts of issues that folks will expect us to fix and we may not have the capacity to tackle in a timely manner. More likely they are tied up in core issues which can sometime take years to resolve.

Not saying we should not go this route but it may not be a “free lunch” so to say.

5

I think the proposal is reasonable, but as Shafik is concerned about, this does an N^2 on our host-compiler support matrix, and increases the number of host-compiler-bugs we’ll have to work around.

I think this could get out of hand in some ways, but I’m not horribly concerned, particularly if we agree to ALSO increase our ‘lower bound’ as well. That is, if we add C++20/C++23 NOW, when it comes to C++26, we need to move our minimum to C++20 if at all possible. That is, ONLY have us support 3 compilers at any one time.

Additionally, if we aren’t going to have a buildbot for the config, this is at best a ‘best effort of reviewers’, so I can’t imagine we are going to do a particularly good job. ADDITIONALLY-ADDITIONALLY: We should NOT permit reverts based on compiler/standards versions NOT in buildbots.

3 Likes
6

I think the point about “only support most recent compilers on most recent standards” is meant exactly to address this.

On the other hand, “latest” quickly becomes “not-so-latest” and then “normal” over time. For example, C++26 is feature-complete and will soon be the “latest” release as work starts on C++29; at that point it gets harder and harder to argue that anything related to C++23 is still “latest”.

In other words, once you introduce C++23 support with a given set of today’s most recent compilers, people will have an IMO justifiable expectation that the lower bounds on those compilers don’t move absent a strong technical reason. So I think that for newer standards, it would make sense to explicitly name the supported toolchains and their lower bounds. This also goes towards the following point

I can understand that it doesn’t make sense to enumerate compilers for baseline support (i.e. being to compile LLVM at all), but I think it would make sense for higher standard revisions, especially if that support hinges essentially on having a buildbot for that combination.

Below is a table how the support matrix could look over time. Obviously not all compiler versions in the range between lowest and most current are necessarily tested on every platform – it’s natural to thin out that range as appropriate. This is not so much a proposal as a thought-experiment how the support matrix would look over time, assuming a lower bound for compiler support per standard revision.

FWIW, the C++17 lower bounds are from here (c.f. also original RFC). C++20 lower bounds are from here, and I took the most recent compilers for C++23.

Time Most recent
releases		 C++17
support		 C++20
support		 C++23
support		 C++26
support
2025H2 Clang: v21
GCC: v15
MSVC: v17.14		 Clang: v5+
GCC: v7+
MSVC: v16.8+
Other: anything
capable of C++17		 Clang: v17+
GCC: v12+
MSVC: v17.2+		 Clang: v21+
GCC: v15+
MSVC: N/A		 N/A
2026H2 Clang: v23
GCC: v16
MSVC: v18.0[1]?		 Clang: v5+
GCC: v7+
MSVC: v16.8+
Other: as above		 Clang: v17+
GCC: v12+
MSVC: v17.2+		 Clang: v21+
GCC: v15+
MSVC: ?		 N/A
2027H2 Clang: v25
GCC: v17
MSVC: v18.x
C++26 ratified[2]		 ? Clang: v17+
GCC: v12+
MSVC: v17.2+
Other: anything
capable of C++20		 Clang: v21+
GCC: v15+
MSVC: ?		 Clang: v25+
GCC: v17+
MSVC: ??

Of course, dropping C++17 and moving to C++20 will be a likely discussion in the coming years, and obviously the lower bounds for the set of tested compilers could be moved up further even while C++17 is still supported (e.g. the 16.x line of MSVC is EOL already). I’m not saying C++17 support should be kept or dropped, but it’s IMO an unavoidable question that will come up when extending support to C++26, whenever that happens.

  1. used to be mentioned on the STL changelog already, but got removed again in May 2025 ↩︎

  2. C++23 was ratified in October 2024, I’m assuming C++26 gets ratified three years later. ↩︎

1 Like
7

Thanks for following up on this.

Would it be worth clarifying what we mean by ‘the latest version’? I assume you mean the most recent release instead of gcc trunk / msvc preview?

Other than that, this seems like a reasonable compromise as long as someone sets up the build bots, and makes sure they keep getting updated to the most recent versions of the toolchains.

8

Yes: release is what is meant here.

9

I think it’s uncontroversial to accept straightforward patches to fix build failures which arise from changes in newer language versions, even when that’s for a configuration that’s not fully supported. So, LLVM may well build with a new standards version, if some members of the community are regularly testing it downstream.

But based on my experience with C++20, I think we should not have a project policy claiming official support for all bleeding-edge standards versions. Even “the latest release of each toolchains” was essentially non-viable for a long time with C++20. I’d say that if someone wants to declare some particular new standards-version as “supported”, they should make a RFC proposing such, along with a certain set of minimum implementation versions which are thought to have mature-enough support for that version.

For C++23 in particular, it may well be reasonable to support it now – it’s around the usual time-since-release where that starts to make sense. I just don’t think we should make a policy of promising support for all new language-versions as soon as they exist. Even if limited to “latest release” of compilers.

3 Likes
10

+1 to what @jyknight said. There’s a big difference between “small straight forward changes by motivated folks” and “supported”. Let’s stick strictly to the former for this thread.

11

It’s not clear to me what’s the suggestion about bots management?

12

I think your original proposed patch looks pretty good, but I’d tweak the sentence on “support” to be a bit more mechanical and say that the minimum supported C++ version and the minimum plus one are versions that are most likely to work due to their more complete CI coverage.

1 Like
13

OK! I am not sure about the use of “plus one”, because that’s too much of a moving target, so I try to be more loose in the language.

Changed the text to:

To keep track with the evolution of the standard, newer C++ version can be used
to build LLVM. However, our support focuses on the minimum supported C++
version and a very recent standard may not be yet supported, or only using the
latest version of the supported toolchains and possibly not across all the
subprojects.

Maybe we should document which bot covers more recent versions of the standard?

I opened a PR: Document Policy on supporting newer C++ standard in LLVM codebase by joker-eph · Pull Request #156823 · llvm/llvm-project · GitHub ; feel free to suggest further edits there.

14

Just a ping on the PR above, it’s been open for almost two week, I’ll merge it by the end of the week absent of any new comment.