Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Wed, 12 Oct 2022 19:36:40 -0600
Message-ID: <CAHmME9prBJHmo9Bw6aobuGLjtxLsjxKJ9wopOv5+BY6ZtuKaNg@mail.gmail.com>
Subject: gcc 5 & 6 & others already out of date?
To:     linux-toolchains@vger.kernel.org,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

I've been working on a (still in development) patch that tries to
apply a few compile-time constant folding tricks to a widely used
library function, so I wanted to make sure my trickery worked across
all supported gcc versions for as many call sites as possible.
Naturally, this means allyesconfig builds on the monster box.

So all went well with a recent gcc and with clang. Then I tried gcc 5
and gcc 6, and it wasn't fine. But it wasn't not fine because of my
new code -- that all compiled just fine. Rather, it wasn't fine
because of a modicum of other odd errors and fatal warnings
throughout. I tried this with gcc 5 and gcc 6 and then got bored. I
could test more versions need be. And I guess I could submit bug
reports or write patches or work on fixing all those, if I actually
cared about it. But I don't really care about it, and apparently
neither does anybody else, because this isn't brand new breakage. And
this all got me thinking...

Linus merged Rust for 6.1, and this relies on unstable features. We're
in for a world of pain, I'm sure, and who knows where this is going to
lead. But what seems clear is that as we figure out how to make Rust
work with the kernel (if we can manage to figure that out, that is),
we're going to likely be bumping the minimum compiler version as the
upstream Rust people implement things we need. And while Rust is used
for nothing today, soon it'll be used for things not exactly optional
for certain segments of users - for example, that Apple GPU driver.
The slow stable days of C are coming to an end, it would seem.

But also, it's not just Rust. Clang support has been an incremental
thing, and the kernel has dropped old Clang versions as they no longer
make sense. Heck, the new KCFI implementation requires bleeding edge
Clang, and the kernel dropped support for the old implementation. So
clearly, the people that use Clang want to use new Clang, not crusty
Clang, and that's sort of the whole point of that being there.

And then there's old trusty gcc. Gcc also improves according to a nice
cadence, and we know people are using later gccs because nobody is
catching the build errors from old gccs. So let's stop pretending we
support old compilers. We clearly don't. Maybe some subset of code
does, but by and large, I doubt many developers are actually daily
driving gcc 5.1 and doing allyesconfig builds with it. Yes, many are
rightfully cautious of gcc 12 and stick with gcc 11 still, and that's
reasonable, but 11 or even 10 is still way larger than 5.1.

The truth is, people tend to use more recent toolchains. And if Clang
hasn't broken the will of the stranglers, then surely Rust will.

So, what are your thoughts on just abandoning this charade all
together, and saying that we support the last 2 or 3 releases of a
compiler (and related toolchain - binutils and such) at the time of
the kernel's release, and admit that our C is a moving target, just as
our Rust inevitably will be. Then we don't have to have these tortured
conversations every few years about 4.9 or 5.1 or 6.3 or whatever
enterprise [il-]logic has tended to dictate how things have worked
until now.

As usual, feel free to chase me off with pitchforks. I'm sure some
RHEL folks hate this. But I think it's at least worth consideration.

Jason