On Wed, Oct 12, 2022 at 6:37 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > 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. I'd imagine the kernel's inconsistent use of -ffreestanding per architecture would be a blocker, if by library function you're referring to a symbol that would typically be provided by the libc? Do you have more info about what the specific issue you've observed is? > 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... Are the defconfigs totally broken with gcc-5 and gcc-6 and no one has noticed? I wonder what versions of GCC KernelCI and linux kernel robot are testing with? We have to maintain CI for all supported clang versions. You can see a 2D slice of our 5D build matrix: https://clangbuiltlinux.github.io/. "I've never seen so much red in the galaxy!" "Hey, get back to work!" We'd like to have the large window of supported versions that GCC currently has; Clang's release cycle is also different from GCC's though. I wouldn't point to clang's smaller version support window as justification for GCC; we'd rather be more like GCC in that sense, not the other way round! -- Thanks, ~Nick Desaulniers
