[RFC]Updating Supported Host Compiler versions for LLVM20

LLVM Project
1

Hi all-
Now that we’ve done the 19.1 branch, I believe it is time again that we discuss what ‘minimum’ compiler version we sh ould support as our host compilers. See the current list here: Getting Started with the LLVM System — LLVM 20.0.0git documentation

At least for the GCC version, the GCC7 branch is a little problematic for us, see here: Unable to use clang header with GCC <9.3 with `-Werror` · Issue #109192 · llvm/llvm-project · GitHub

One thing to note: This was NOT caught by any buildbots, despite being committed in May. So this shows that we don’t have any buildbots for GCC7.

As a part of this, I’d like to get a good idea of what our current buildbot compiler versions are? It seems foolish for us to list supported host compilers that we don’t actually TEST.

As far as versions, the above shows that we should consider at least the GCC8.4 as our minimum version. Based on that, I’m going to make my proposal as follows, though if someone has reason one way or another on any of the compilers, I’d love to hear them. Additionally, I’d like to see us start having buildbots for our minimum version (and presence of existing buildbot versions would, IMO, be extremely motivating for setting these versions).

GCC: 8.5, May 2021 release date (latest of the GCC 8 branch). Looks like all major distributions have at least this version.

Clang: 11.1.0, February 2021 release date. This is the most similar date-wise to the GCC proposal above, otherwise no real motivation

Apple Clang 13.4.1, June 2022 release date: No reason, other than it is 3 versions of XCode-old. I don’t have good visibility into what LLVM/Clang this is based on, but timeframe wise seems appropriate.

Visual Studio 2019 16.10.4, released July 2021: This is the latest version of the VS 2019 branch, anything newer looks to be VS2022. That said, with as easy as updating Visual Studio IS, I might suggest we consider 2022.

So: Request for Comments :slight_smile:

5 Likes
2

One thing to note: This was NOT caught by any buildbots, despite being committed in May. So this shows that we don’t have any buildbots for GCC7.

Note, that this is not exactly true. We may not have any buildbots with GCC7 that compile code that includes this header with -Werror (don’t think most buildbots treat warnings as errors anyway).

So I don’t see how this conclusion follows

As far as versions, the above shows that we should consider at least the GCC8.4 as our minimum version.

1 Like
3

FWIW, we have bots working just fine older than that:

VCTOOLSVERSION=14.28.29333
VISUALSTUDIOVERSION=16.0
...
VSCMD_VER=16.8.7

from Buildbot

I’m not certain we need to bump anything for MSVC, but I’ll let @rnk weigh in as he’s the owner of the MSVC bots.

Based on the issues that get filed, I think that -Werror is the bar for what’s expected to be the minimum version we support. Folks consuming the libraries we produce should not have to disable -Werror if we can avoid it. So I think what Erich is asking for is for the bots currently handling our minimum configurations to enable -Werror.

4

Thanks a lot for driving this

last time I looked into it, gcc 8.5 was available in LTS versions of all distributions, so this seems reasonable as far as gcc is concerned.

Independently of your motivation, I welcome this RFC as I have been itching to use bitfields in-class default member initializers in clang, which gcc doesn’t support until, I believe, 8.4 (and I am sure there are others feature we could leverage, I just did not look into it too deeply).

1 Like
5

I think there is difference between “consuming a library” and “compiling llvm library”. If it’s a header expected to be included by library users, sure. If it’s internal llvm header, then I don’t think -Werror is a reasonable expectation. Warnings are not stable. Furthermore, each new compiler release adds new ones (or changes older ones) so if we claim “builds with -Werror” as our requirement to say the compiler is supported, then we’ll need to have -Werror buildbots for each new GCC version that is released.

6

It was my understanding that LLVM is only supposed to be -Werror clean on recent clang – warning freedom on GCC is best effort, and the effort is not even particularly good. At least before I switched to building with clang a while ago, the number of warnings a build with GCC produces was very substantial.

If -Werror is the bar, then LLVM does not support building with GCC at all.

I know that there is at least one buildbot (mlir-nvidia-gcc7) maintained by @mehdi_amini testing that LLVM and MLIR build with GCC 7. I’m not sure if there is one covering Clang. Of course, it is not a -Werror buildbot.

From my side (with my Rust hat on), I don’t particularly care about GCC 7 support – we have found it to be unsuitable because it does not have stable C++ 17 ABI, so using it is more trouble than it’s worth. We do have a lot of cross-compilation configurations using GCC 8, and it’s not always the very latest one.

In any case, even if we do want to drop GCC 7 support (for which warnings are IMHO not a good motivation), it shouldn’t be an excuse to also raise minimums for other compilers, without at least some justification.

2 Likes
7

That just does not seem realistic to me: some gcc versions have some obnoxious warnings that we even disable explicitly in CMake (and if you can’t pass -Wno-error to users, how can you pass these -Wno-… ?).
There are been occasions of warnings being even in conflict between clang and gcc: that is clang would warn on the gcc-suggested code and vice-versa.

Correction: that just means we don’t have gcc7 build bots building with Werror.

I maintain such bot for LLVM/MLIR because we (Nvidia) care about this toolchain for our usage of LLVM (and some subprojects), I just don’t bother with warnings at all for gcc.

1 Like
8

FWIW, I build LLVM/Clang with GCC quite a lot. It’s never warning free, but I try to do something about it if there are large numbers of new warnings.

9

Following the transition from GCC 7.1 to GCC 7.4 in July 2023 (⚙ D156286 [docs] Bump minimum GCC version to 7.4),
we’ve seen challenges maintaining compatibility with 7.* and <8.4.
For example, Extend GCC workaround to GCC < 8.4 for llvm::iterator_range ctor by RoboTux · Pull Request #82643 · llvm/llvm-project · GitHub added workarounds for 7.* and <8.4.

With Fedora’s transition to Clang for building LLVM, ensuring buildability across various older GCC versions has become even more complex.

I agree that -Werror is not a good signal for GCC buildability.
That said, while GCC 7.4 and 7.5 might be still working for some configurations (or not for certain important configurations; haven’t bothered checking),
I believe maintaing their support is very challenging.

Bumping the minimum required GCC version to 8.5 looks good to me.

Ideally we should have a list of known working minor versions for each release branch.
For example, it’s possible that GCC 9.3 works while GCC 9.2 doesn’t, even if GCC 8.5 works.

I believe that a significant of the community doesn’t check buildability with an old GCC version that is more than 4 years old. Ensuring builkdability really requires the stakeholder to contribute a build bot.

Clang: 11.1.0, February 2021 release date. This is the most similar date-wise to the GCC proposal above, otherwise no real motivation

LGTM from my perspective. Unlike GCC, people using Clang usually use quite new Clang.

FWIW: I’ve recent tried building llvm-project with Clang 7 and failed (when using libstdc++ from GCC 14).
I have just checked that Clang 9 using GCC 14 works.

1 Like
10

I often build on a shared machine, with Xcode/Apple Clang 12.5 (I think) installed; according to Xcode - Wikipedia, that corresponds to Clang 11.0. So if we don’t have any specific reasons for picking one version over another, I’d prefer to lower the requirement to include Apple Clang 12.5 at least.

In some cases, I build with distro-provided versions of Clang. In the case of Ubuntu 20.04, that’s Clang 10.0.

11

The last one in the VS2019 line is VS 16.11. No other minor versions are supported anymore, and all but 16.11 have already been dropped from microsoft’s CI image (GHA & Azure Pipelines). I don’t know how the build windows build bots are set up, but anything below 16.11 seems of questionable added value IMO.

12

I agree with the other comments that a -Werror bar for GCC builds seems unachievable. We see larger numbers of warning with GCC across the different versions we use.

It is not completely true that there are no buildbots for GCC 7. I maintain a small fleet of buildbots, including a SLES-15 SP4 bot that comes with GCC 7.5, since we (AMD) care about that compiler-toolchain for a few subprojects. Those subprojects are enabled on that buildbot, and it seems that the configuration we run was unaffected by that change, as we do not compile with -Werror.

13

I think there are different expectations for different constituencies. There’s what we think we can reasonably do (and FWIW, I agree that -Werror is an incredibly high bar) and there’s what people outside of the community expect us to do. Approximately every release sees people filing issues about not being able to build with -Werror and we don’t document anything to the contrary. (Also, keep in mind that “consuming a library” and “compiling LLVM library” are the same thing in many cases – people who build plugins have to build them against the LLVM sources because we have no ABI stability guarantees for the C++ APIs.) But this is what I meant when I said “Based on the issues that get filed,” – I think the outside perspective is different from the inside perspective.

If the community doesn’t want to promise an ability to compile with -Werror, I think we should explicitly document that. Then when people inevitably file issues about that configuration not working, issue triagers have a documented policy they can point people to when closing the issue. But the current situation definitely sees an expectation that we are warning-free in terms of people filing issues when you look through the bug tracker.

1 Like
14

Then this is a wrong expectation and should be documented. Eliminating warnings should be generally on a best-effort basis (since as mentioned in other comments - it’s not even theoretically possible due to different compilers disagreeing on what they warn against unless we start adding a bunch of “pragma warning push/pop” which is not maintainable and can be done by the consumers themselves).

15

Changing the supported host compiler versions is not as easy as you think, see:

16

I’m aware it is painful. Note I was the ‘first’ one to do it that got us off of GCC4.7. This is very much a request for ‘comment’, which I’m glad we’re getting, there is definitely enlightening things happening.

As far as warning-clean: I think we SHOULD be able to be Werror clean. If that requires our build-scripts having explicit warning-disables for certain compilers, than so-be-it, but being warning clean is very important to at least some of our consumers.

4 Likes
17

I think it’s a good ideal to strive for, but I think it’s functionally impossible unless we have post-commit CI testing each compiler version of each supported compiler, which is a tall order I don’t think we can accomplish.

I mostly brought up -Werror cleanliness because of the disconnect between what we document (which is nothing), what we do (which is best effort but aims for warning-free with the latest versions of the major compilers or the configurations with post-commit CI validation), and what others outside of the community expect (which is -Werror clean, at least based on the frequency of issues that get filed).

However, this is also orthogonal to this RFC which is about what our base compiler should be. So perhaps a good way forward is: let’s agree to document that there should be no expectation that we’re warning free on all compilers and compiler versions but we aim to be warning free (and welcome patches addressing true positive issues found by warnings!). Then, if someone feels strongly that we should be warning-free, they can post an RFC explaining how that works in practice.

4 Likes
18

As an alternative to this proposal, I’d very much be OK documenting to users that we dont’ strive to be -Werror clean. I think we still want to accept patches that get us CLOSER to there (in a realistic-code-is-improved sense), but would mean we could reject suggested patches like the one I brought up in the OP.

5 Likes
19

I think that’s reasonable as well. My primary concern is: let’s get it written down somewhere so we’re setting expectations rather than letting people’s imaginations set those expectations for us.

20

+1 on documenting the existing status quo. We are not -Werror clean on all reasonable toolchains, and never had been.

I second the aspirational framing on being -Werror clean. We can (and do, and have) accepted patches for older toolchains, but they have to be a net improvement to the codebase.

I think it would be reasonable to propose (i.e. a separate RFC thread) a very narrow set of toolchains on which we are -Werror clean, but that’s a different discussion. The only one I think which might be really realistic would be clang itself (as in, requirement applies only to a clang built with that exact clang revision.)

I’ll note that being -Werror clean on all toolchains is economically non-viable. We’d have to find a whole bunch of money to run builders with a large cross product of toolchains. We could potentially do -fsyntax-only style builders, but this is still a huge amount of work, and expensive. Personally, I see this as being a high cost, low reward activity.

1 Like