[Intel-gfx] [PATCH] Kbuild: remove -std=gnu89 from compiler arguments

Arnd Bergmann arnd at kernel.org
Mon Feb 28 08:07:03 UTC 2022

On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> And I don't want somebody with a newer compiler version to not notice
> that he or she ended up using a c17 feature, just because _that_
> compiler supported it, and then other people get build errors because
> their compilers use gnu11 instead by default.
> Put another way: I see absolutely no upside to allowing different
> users using higher/lower versions of the standard. There are only
> downsides.
> If gnu11 is supported by gcc-5.1 and up, and all the relevant clang
> versions, then let's just pick that.

Ok, changed my patch to -gnu11 now.

> And if there are any possible future advantages to gnu17 (or eventual
> gnu2x versions), let's document those, so that we can say "once our
> compiler version requirements go up sufficiently, we'll move to gnuXX
> because we want to take advantage of YY".
> Please?

I think all of the options here are equally bad: picking gnu11 means
we use a non-standard default for anything other than gcc-5 and
may get surprised again in the future when we want to change to
a newer version; -std=gnu1x would work as an alias for gnu17 in
all versions including gcc-5 but is already marked as 'deprecated'
in the gcc documentation; and using -std=gnu17 for modern compilers
requires a workaround for gcc-7 and earlier.

Regarding new features from gcc-2x, I think we already use
most of what is listed in https://en.wikipedia.org/wiki/C2x, as
those are all GNU extensions that are valid in modern gnu89 as
well. Newly added features seem to only depend on the compiler
version, e.g. #elifdef works in both clang-13 and gcc-12 with
any -std=gnu?? argument, so picking an earlier standard won't
stop people from breaking the build with older compilers.


More information about the Intel-gfx mailing list