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
