[v2] Kbuild: move to -std=gnu11

Commit Message

Arnd Bergmann Feb. 28, 2022, 10:27 a.m. UTC

From: Arnd Bergmann <[e-mail]>

During a patch discussion, Linus brought up the option of changing
the C standard version from gnu89 to gnu99, which allows using variable
declaration inside of a for() loop. While the C99, C11 and later standards
introduce many other features, most of these are already available in
gnu89 as GNU extensions as well.

An earlier attempt to do this when gcc-5 started defaulting to
-std=gnu11 failed because at the time that caused warnings about
designated initializers with older compilers. Now that gcc-5.1 is the
minimum compiler version used for building kernels, that is no longer a
concern. Similarly, the behavior of 'inline' functions changes between
gnu89 and gnu11, but this was taken care of by defining 'inline' to
include __attribute__((gnu_inline)) in order to allow building with
clang a while ago.

One minor issue that remains is an added gcc warning for shifts of
negative integers when building with -Werror, which happens with the
'make W=1' option, as well as for three drivers in the kernel that always
enable -Werror, but it was only observed with the i915 driver so far.
To be on the safe side, add -Wno-shift-negative-value to any -Wextra
in a Makefile.

Nathan Chancellor reported an additional -Wdeclaration-after-statement
warning that appears in a system header on arm, this still needs a
workaround.

The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
minimal and mainly impact warnings at the -Wpedantic level that the
kernel never enables. Between these, gnu11 is the newest version
that is supported by all supported compiler versions, though it is
only the default on gcc-5, while all other supported versions of
gcc or clang default to gnu1x/gnu17.

Link: https://lore.kernel.org/lkml/CAHk-=[e-mail]/
Link: https://github.com/ClangBuiltLinux/linux/issues/1603
Suggested-by: Linus Torvalds <[e-mail]>
Cc: Masahiro Yamada <[e-mail]>
Cc: [e-mail]
Cc: [e-mail]
Signed-off-by: Arnd Bergmann <[e-mail]>
---
[v2]
 - added -std=gnu11 back, rather than just relying on the default
 - minor changes to changelog text
---
 Documentation/process/programming-language.rst              | 4 ++--
 .../translations/it_IT/process/programming-language.rst     | 4 ++--
 .../translations/zh_CN/process/programming-language.rst     | 4 ++--
 .../translations/zh_TW/process/programming-language.rst     | 4 ++--
 Makefile                                                    | 6 +++---
 arch/arm64/kernel/vdso32/Makefile                           | 2 +-
 drivers/gpu/drm/i915/Makefile                               | 1 +
 drivers/staging/greybus/tools/Makefile                      | 3 ++-
 fs/btrfs/Makefile                                           | 1 +
 scripts/Makefile.extrawarn                                  | 1 +
 10 files changed, 17 insertions(+), 13 deletions(-)

Comments

Arnd Bergmann Feb. 28, 2022, 11:57 a.m. UTC | #1

On Mon, Feb 28, 2022 at 12:47 PM Marco Elver <[e-mail]> wrote:
> On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann <[e-mail]> wrote:
>
> > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > warning that appears in a system header on arm, this still needs a
> > workaround.
>
> On the topic of Wdeclaration-after-statement, Clang only respects this
> warning with C99 and later starting with Clang 14:
> https://github.com/llvm/llvm-project/commit/c65186c89f35#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97R61
>
> Until Clang 14, -Wdeclaration-after-statement is ignored by Clang in
> newer standards. If this is a big problem, we can probably convince
> the Clang stable folks to backport the fixes. However, the build won't
> fail, folks might just miss the warning if they don't also test with
> GCC.

I don't expect this is to be a big issue, as long as the latest clang behaves
as expected. There are many warnings that are only produced by one of the
two compilers, so this is something we already deal with.

I think it's more important to address the extra warning that Nathan
reported, where clang now complains about the intermingled declaration
in a system header when previously neither gcc nor clang noticed this.

> > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
> > minimal and mainly impact warnings at the -Wpedantic level that the
> > kernel never enables. Between these, gnu11 is the newest version
> > that is supported by all supported compiler versions, though it is
> > only the default on gcc-5, while all other supported versions of
> > gcc or clang default to gnu1x/gnu17.
> >
> > Link: https://lore.kernel.org/lkml/CAHk-=[e-mail]/
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1603
> > Suggested-by: Linus Torvalds <[e-mail]>
> > Cc: Masahiro Yamada <[e-mail]>
> > Cc: [e-mail]
> > Cc: [e-mail]
> > Signed-off-by: Arnd Bergmann <[e-mail]>
>
> Acked-by: Marco Elver <[e-mail]>

Thanks,

         Arnd

Nathan Chancellor Feb. 28, 2022, 4:56 p.m. UTC | #2

On Mon, Feb 28, 2022 at 12:57:55PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 28, 2022 at 12:47 PM Marco Elver <[e-mail]> wrote:
> > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann <[e-mail]> wrote:
> >
> > > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > > warning that appears in a system header on arm, this still needs a
> > > workaround.
> >
> > On the topic of Wdeclaration-after-statement, Clang only respects this
> > warning with C99 and later starting with Clang 14:
> > https://github.com/llvm/llvm-project/commit/c65186c89f35#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97R61
> >
> > Until Clang 14, -Wdeclaration-after-statement is ignored by Clang in
> > newer standards. If this is a big problem, we can probably convince
> > the Clang stable folks to backport the fixes. However, the build won't
> > fail, folks might just miss the warning if they don't also test with
> > GCC.

Unfortunately, none of the branches prior to release/14.x are going to
see any more updates (at least as far as I am aware, as the LLVM
community only supports one release branch at a time) but as Arnd
mentioned below, I do not really see that as a problem, as newer
versions of clang and GCC will catch these warnings.

> I don't expect this is to be a big issue, as long as the latest clang behaves
> as expected. There are many warnings that are only produced by one of the
> two compilers, so this is something we already deal with.
> 
> I think it's more important to address the extra warning that Nathan
> reported, where clang now complains about the intermingled declaration
> in a system header when previously neither gcc nor clang noticed this.

Right. Based on the upstream LLVM bug, I think we should just fix
arm_neon.h to avoid triggering -Wdeclaration-after-statement to have
something that is (hopefully) relatively low risk for a clang-14
backport, rather than addressing the root cause of clang warning in
system macros, as it sounds like fixing that has some risks that are not
fully understood at this point. The kernel only uses very specific
system headers after commit 04e85bbf71c9 ("isystem: delete global
-isystem compile option"), so I don't think that my suggested approach
will have many downsides.

I think I see how to potentially fix arm_neon.h in
clang/utils/TableGen/NeonEmitter.cpp, I just have to think about it a
little more.

Realistically, I don't think special casing this in lib/raid6 is the end
of the world:

diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 45e17619422b..a41ff71b90af 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -38,6 +38,10 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
 NEON_FLAGS := -ffreestanding
 # Enable <arm_neon.h>
 NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include)
+# https://github.com/ClangBuiltLinux/linux/issues/1603
+ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_CPU_BIG_ENDIAN),yy)
+NEON_FLAGS += -Wno-declaration-after-statement
+endif
 ifeq ($(ARCH),arm)
 NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
 endif

> > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
> > > minimal and mainly impact warnings at the -Wpedantic level that the
> > > kernel never enables. Between these, gnu11 is the newest version
> > > that is supported by all supported compiler versions, though it is
> > > only the default on gcc-5, while all other supported versions of
> > > gcc or clang default to gnu1x/gnu17.
> > >
> > > Link: https://lore.kernel.org/lkml/CAHk-=[e-mail]/
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603
> > > Suggested-by: Linus Torvalds <[e-mail]>
> > > Cc: Masahiro Yamada <[e-mail]>
> > > Cc: [e-mail]
> > > Cc: [e-mail]
> > > Signed-off-by: Arnd Bergmann <[e-mail]>
> >
> > Acked-by: Marco Elver <[e-mail]>

Cheers,
Nathan

Masahiro Yamada Feb. 28, 2022, 5:02 p.m. UTC | #3

On Mon, Feb 28, 2022 at 7:32 PM Arnd Bergmann <[e-mail]> wrote:
>
> From: Arnd Bergmann <[e-mail]>
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later standards
> introduce many other features, most of these are already available in
> gnu89 as GNU extensions as well.
>
> An earlier attempt to do this when gcc-5 started defaulting to
> -std=gnu11 failed because at the time that caused warnings about
> designated initializers with older compilers. Now that gcc-5.1 is the
> minimum compiler version used for building kernels, that is no longer a
> concern. Similarly, the behavior of 'inline' functions changes between
> gnu89 and gnu11, but this was taken care of by defining 'inline' to
> include __attribute__((gnu_inline)) in order to allow building with
> clang a while ago.
>
> One minor issue that remains is an added gcc warning for shifts of
> negative integers when building with -Werror, which happens with the

Is this a typo?

   building with -Werror, ...
->
   building with -Wextra, ...




> 'make W=1' option, as well as for three drivers in the kernel that always
> enable -Werror, but it was only observed with the i915 driver so far.

Same here.

   enable -Werror, but ...
->
  enable -Wextra, but ...




Otherwise,

Acked-by: Masahiro Yamada <[e-mail]>


Please let me know if you want me to pick up this.









--
Best Regards

Masahiro Yamada

Masahiro Yamada Feb. 28, 2022, 5:07 p.m. UTC | #4

On Mon, Feb 28, 2022 at 8:25 PM Mark Rutland <[e-mail]> wrote:
>
> Hi Arnd,
>
> This is great!
>
> On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <[e-mail]>
> >
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 to gnu99, which allows using variable
> > declaration inside of a for() loop. While the C99, C11 and later standards
> > introduce many other features, most of these are already available in
> > gnu89 as GNU extensions as well.
> >
> > An earlier attempt to do this when gcc-5 started defaulting to
> > -std=gnu11 failed because at the time that caused warnings about
> > designated initializers with older compilers. Now that gcc-5.1 is the
> > minimum compiler version used for building kernels, that is no longer a
> > concern. Similarly, the behavior of 'inline' functions changes between
> > gnu89 and gnu11, but this was taken care of by defining 'inline' to
> > include __attribute__((gnu_inline)) in order to allow building with
> > clang a while ago.
> >
> > One minor issue that remains is an added gcc warning for shifts of
> > negative integers when building with -Werror, which happens with the
> > 'make W=1' option, as well as for three drivers in the kernel that always
> > enable -Werror, but it was only observed with the i915 driver so far.
> > To be on the safe side, add -Wno-shift-negative-value to any -Wextra
> > in a Makefile.
> >
> > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > warning that appears in a system header on arm, this still needs a
> > workaround.
>
> FWIW, I had a go at moving to c99 a few weeks ago (to be able to use
> for-loop-declarations in some concurrency primitives), and when I tried, I also
> saw declaration-after-statement warnings when building modpost.c, which is easy
> enough to fix:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=treewide/gnu99&id=505775bd6fd0bc1883f3271f826963066bbdc194
>


I do not understand this statement:

"Usually such warnings are implciitly enabled as part of `-std=gnu89`,
 and in preparation for changing the standard used, this patch explciitly
enales the warnings with `-Wdeclaration-after-statement`, which takes
effect regardless of which version of the C standard is in use."



modpost is already built with -std=gnu89.

If  Wdeclaration-after-statement is implied by gnu89,
why did nobody notice this before?

Arnd Bergmann Feb. 28, 2022, 6:24 p.m. UTC | #5

On Mon, Feb 28, 2022 at 6:02 PM Masahiro Yamada <[e-mail]> wrote:
>
> On Mon, Feb 28, 2022 at 7:32 PM Arnd Bergmann <[e-mail]> wrote:
> >
> > From: Arnd Bergmann <[e-mail]>
> >
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 to gnu99, which allows using variable
> > declaration inside of a for() loop. While the C99, C11 and later standards
> > introduce many other features, most of these are already available in
> > gnu89 as GNU extensions as well.
> >
> > An earlier attempt to do this when gcc-5 started defaulting to
> > -std=gnu11 failed because at the time that caused warnings about
> > designated initializers with older compilers. Now that gcc-5.1 is the
> > minimum compiler version used for building kernels, that is no longer a
> > concern. Similarly, the behavior of 'inline' functions changes between
> > gnu89 and gnu11, but this was taken care of by defining 'inline' to
> > include __attribute__((gnu_inline)) in order to allow building with
> > clang a while ago.
> >
> > One minor issue that remains is an added gcc warning for shifts of
> > negative integers when building with -Werror, which happens with the
>
> Is this a typo?
>
>    building with -Werror, ...
> ->
>    building with -Wextra, ...
>

I'm being slow today, Jani actually pointed out the same thing and I
misunderstood him. Fixed it now, thanks!

> Acked-by: Masahiro Yamada <[e-mail]>
>
>
> Please let me know if you want me to pick up this.

Yes, that would be great. I'll send a v3 with the updated changelog,
but will drop most of the Cc list as there are no functional changes.

        Arnd

Linus Torvalds Feb. 28, 2022, 6:40 p.m. UTC | #6

On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann <[e-mail]> wrote:
>
> I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it
> make sense regardless of the -std=gnu11 change

I do think they make sense, but I want to note again that people doing
cross builds obviously use different tools for user builds than for
the kernel. In fact, even not cross-building, we've had situations
where the "kbuild" compiler is different from the host compiler,
because people have upgraded one but not the other (upgrading the
kernel build environment is actually much easier than upgrading the
host build environment, because you don't need all the random
libraries etc, and you can literally _just_ build your own gcc and
binutils)

And we have *not* necessarily required that the host tools match the
kernel tools.

So I could well imagine that there are people who build their kernels,
but their host build environment might be old enough that -std=gnu11
is problematic for that part.

And note how any change to  KBUILD_USERCFLAGS is reflected in KBUILD_HOSTCFLAGS.

So I would suggest that the KBUILD_USERCFLAGS part of the patch (and
the modpost.c change that goes with it) be done as a separate commit.
Because we might end up reverting that part.

Hmm?

           Linus

Nick Desaulniers Feb. 28, 2022, 9:03 p.m. UTC | #7

On Mon, Feb 28, 2022 at 2:32 AM Arnd Bergmann <[e-mail]> wrote:
>
> From: Arnd Bergmann <[e-mail]>
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later standards
> introduce many other features, most of these are already available in
> gnu89 as GNU extensions as well.
>
> An earlier attempt to do this when gcc-5 started defaulting to
> -std=gnu11 failed because at the time that caused warnings about
> designated initializers with older compilers. Now that gcc-5.1 is the
> minimum compiler version used for building kernels, that is no longer a
> concern. Similarly, the behavior of 'inline' functions changes between

More precisely, the semantics of "extern inline" functions changed
between ISO C90 and ISO C99.

That's the only concern I have, which I doubt is an issue. The kernel
is already covered by the function attribute as you note.

Just to have some measure:
$ git grep -rn "extern inline" | wc -l
116

Most of those are in arch/alpha/ which is curious; I wonder if those
were intentional.

(I do worry about Makefiles that completely reset KBUILD_CFLAGS
though; the function attributes still take precedence).

> gnu89 and gnu11, but this was taken care of by defining 'inline' to
> include __attribute__((gnu_inline)) in order to allow building with
> clang a while ago.
>
> One minor issue that remains is an added gcc warning for shifts of
> negative integers when building with -Werror, which happens with the
> 'make W=1' option, as well as for three drivers in the kernel that always
> enable -Werror, but it was only observed with the i915 driver so far.
> To be on the safe side, add -Wno-shift-negative-value to any -Wextra
> in a Makefile.
>
> Nathan Chancellor reported an additional -Wdeclaration-after-statement
> warning that appears in a system header on arm, this still needs a
> workaround.

Ack; I think we can just fix this in clang.

>
> The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
> minimal and mainly impact warnings at the -Wpedantic level that the
> kernel never enables. Between these, gnu11 is the newest version
> that is supported by all supported compiler versions, though it is
> only the default on gcc-5, while all other supported versions of
> gcc or clang default to gnu1x/gnu17.

I agree. With the fixup to s/Werror/Wextra.

Reviewed-by: Nick Desaulniers <[e-mail]>

>
> Link: https://lore.kernel.org/lkml/CAHk-=[e-mail]/
> Link: https://github.com/ClangBuiltLinux/linux/issues/1603
> Suggested-by: Linus Torvalds <[e-mail]>
> Cc: Masahiro Yamada <[e-mail]>
> Cc: [e-mail]
> Cc: [e-mail]
> Signed-off-by: Arnd Bergmann <[e-mail]>

Fangrui Song Feb. 28, 2022, 9:41 p.m. UTC | #8

Thanks for the patch!

(Was always wondering which of binutils and kernel would migrate to C99+
earlier... binutils won)

On 2022-02-28, Nick Desaulniers wrote:
>On Mon, Feb 28, 2022 at 2:32 AM Arnd Bergmann <[e-mail]> wrote:
>>
>> From: Arnd Bergmann <[e-mail]>
>>
>> During a patch discussion, Linus brought up the option of changing
>> the C standard version from gnu89 to gnu99, which allows using variable
>> declaration inside of a for() loop. While the C99, C11 and later standards
>> introduce many other features, most of these are already available in
>> gnu89 as GNU extensions as well.
>>
>> An earlier attempt to do this when gcc-5 started defaulting to
>> -std=gnu11 failed because at the time that caused warnings about
>> designated initializers with older compilers. Now that gcc-5.1 is the
>> minimum compiler version used for building kernels, that is no longer a
>> concern. Similarly, the behavior of 'inline' functions changes between
>
>More precisely, the semantics of "extern inline" functions changed
>between ISO C90 and ISO C99.

Perhaps a clearer explanation to readers is: "extern inline" and "inline" swap
semantics with gnu_inline (-fgnu89-inline or __attribute__((__gnu_inline__))).

>That's the only concern I have, which I doubt is an issue. The kernel
>is already covered by the function attribute as you note.
>
>Just to have some measure:
>$ git grep -rn "extern inline" | wc -l
>116

"^inline" behaves like C99+ "extern inline"

Agree this is handled by

     #define inline inline __gnu_inline __inline_maybe_unused notrace

>Most of those are in arch/alpha/ which is curious; I wonder if those
>were intentional.
>
>(I do worry about Makefiles that completely reset KBUILD_CFLAGS
>though; the function attributes still take precedence).
>
>> gnu89 and gnu11, but this was taken care of by defining 'inline' to
>> include __attribute__((gnu_inline)) in order to allow building with
>> clang a while ago.
>>
>> One minor issue that remains is an added gcc warning for shifts of
>> negative integers when building with -Werror, which happens with the
>> 'make W=1' option, as well as for three drivers in the kernel that always
>> enable -Werror, but it was only observed with the i915 driver so far.
>> To be on the safe side, add -Wno-shift-negative-value to any -Wextra
>> in a Makefile.
>>
>> Nathan Chancellor reported an additional -Wdeclaration-after-statement
>> warning that appears in a system header on arm, this still needs a
>> workaround.
>
>Ack; I think we can just fix this in clang.
>
>>
>> The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
>> minimal and mainly impact warnings at the -Wpedantic level that the
>> kernel never enables. Between these, gnu11 is the newest version
>> that is supported by all supported compiler versions, though it is
>> only the default on gcc-5, while all other supported versions of
>> gcc or clang default to gnu1x/gnu17.
>
>I agree. With the fixup to s/Werror/Wextra.
>
>Reviewed-by: Nick Desaulniers <[e-mail]>
>
>>
>> Link: https://lore.kernel.org/lkml/CAHk-=[e-mail]/
>> Link: https://github.com/ClangBuiltLinux/linux/issues/1603
>> Suggested-by: Linus Torvalds <[e-mail]>
>> Cc: Masahiro Yamada <[e-mail]>
>> Cc: [e-mail]
>> Cc: [e-mail]
>> Signed-off-by: Arnd Bergmann <[e-mail]>
>
>-- 
>Thanks,
>~Nick Desaulniers
>

Miguel Ojeda March 1, 2022, 10:43 a.m. UTC | #9

On Mon, Feb 28, 2022 at 11:32 AM Arnd Bergmann <[e-mail]> wrote:
>
> -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90
> -(including some C99 features). ``clang`` [clang]_ is also supported, see
> +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11
> +(including some C17 features). ``clang`` [clang]_ is also supported, see

I think the "(including some C17)" bit would not make much sense
anymore. There were no major changes in C17 and GCC implements
`-std=c11` and `-std=c17` as basically the same thing according to the
docs (and GNU extensions apply equally to both, I would assume).

When I wrote the "(including some C99 features)" I meant that GCC
implemented some C99 features as extensions in C90 mode, and the
kernel used some of those (e.g. the now gone VLAs).

With that changed, for `programming-language.rst`:

Reviewed-by: Miguel Ojeda <[e-mail]>

Cheers,
Miguel

Arnd Bergmann March 1, 2022, 2:44 p.m. UTC | #10

On Tue, Mar 1, 2022 at 11:43 AM Miguel Ojeda
<[e-mail]> wrote:
>
> On Mon, Feb 28, 2022 at 11:32 AM Arnd Bergmann <[e-mail]> wrote:
> >
> > -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90
> > -(including some C99 features). ``clang`` [clang]_ is also supported, see
> > +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11
> > +(including some C17 features). ``clang`` [clang]_ is also supported, see
>
> I think the "(including some C17)" bit would not make much sense
> anymore. There were no major changes in C17 and GCC implements
> `-std=c11` and `-std=c17` as basically the same thing according to the
> docs (and GNU extensions apply equally to both, I would assume).

Ok, changed now.

> When I wrote the "(including some C99 features)" I meant that GCC
> implemented some C99 features as extensions in C90 mode, and the
> kernel used some of those (e.g. the now gone VLAs).

I suppose it's still true for some c2x features (static_assert, fallthrough,
binary literals, ...), but it seems easier to just leave it out.

> With that changed, for `programming-language.rst`:
>
> Reviewed-by: Miguel Ojeda <[e-mail]>

Thanks.

Arnd Bergmann March 1, 2022, 2:45 p.m. UTC | #11

On Mon, Feb 28, 2022 at 10:41 PM Fangrui Song <[e-mail]> wrote:
> >
> >More precisely, the semantics of "extern inline" functions changed
> >between ISO C90 and ISO C99.
>
> Perhaps a clearer explanation to readers is: "extern inline" and "inline" swap
> semantics with gnu_inline (-fgnu89-inline or __attribute__((__gnu_inline__))).
>
> >That's the only concern I have, which I doubt is an issue. The kernel
> >is already covered by the function attribute as you note.
> >
> >Just to have some measure:
> >$ git grep -rn "extern inline" | wc -l
> >116
>
> "^inline" behaves like C99+ "extern inline"
>
> Agree this is handled by
>
>      #define inline inline __gnu_inline __inline_maybe_unused notrace
>

Ok, I've reworded it again, but kept it a bit shorter, I don't think we
need the full explanation in this patch description in the end.

Thanks,

      Arnd

Guenter Roeck May 16, 2022, 1:10 p.m. UTC | #12

On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <[e-mail]>
> 
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. While the C99, C11 and later standards
> introduce many other features, most of these are already available in
> gnu89 as GNU extensions as well.

The downside is that backporting affected patches to older kernel branches
now fails with error messages such as

mm/kfence/core.c: In function ‘kfence_init_pool’:
mm/kfence/core.c:595:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode

Just something to keep in mind when writing patches.

Guenter

Greg Kroah-Hartman May 16, 2022, 1:31 p.m. UTC | #13

On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote:
> On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <[e-mail]>
> > 
> > During a patch discussion, Linus brought up the option of changing
> > the C standard version from gnu89 to gnu99, which allows using variable
> > declaration inside of a for() loop. While the C99, C11 and later standards
> > introduce many other features, most of these are already available in
> > gnu89 as GNU extensions as well.
> 
> The downside is that backporting affected patches to older kernel branches
> now fails with error messages such as
> 
> mm/kfence/core.c: In function ‘kfence_init_pool’:
> mm/kfence/core.c:595:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
> 
> Just something to keep in mind when writing patches.

I just ran across this very issue on this commit.  It's an easy fixup
for 5.17.y to make this work, so I did that in my tree.  If this gets to
be too much, we might need to reconsider adding c11 to older stable
kernels.

thanks,

greg k-h

Guenter Roeck May 16, 2022, 2:19 p.m. UTC | #14

On 5/16/22 06:31, Greg KH wrote:
> On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote:
>> On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
>>> From: Arnd Bergmann <[e-mail]>
>>>
>>> During a patch discussion, Linus brought up the option of changing
>>> the C standard version from gnu89 to gnu99, which allows using variable
>>> declaration inside of a for() loop. While the C99, C11 and later standards
>>> introduce many other features, most of these are already available in
>>> gnu89 as GNU extensions as well.
>>
>> The downside is that backporting affected patches to older kernel branches
>> now fails with error messages such as
>>
>> mm/kfence/core.c: In function ‘kfence_init_pool’:
>> mm/kfence/core.c:595:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
>>
>> Just something to keep in mind when writing patches.
> 
> I just ran across this very issue on this commit.  It's an easy fixup
> for 5.17.y to make this work, so I did that in my tree.  If this gets to
> be too much, we might need to reconsider adding c11 to older stable
> kernels.
> 

I think I'll do just that for ChromeOS; I don't want to have to deal
with the backports, and we are using recent compilers anyway.

Guenter

Guenter Roeck May 18, 2022, 2:07 p.m. UTC | #15

On 5/18/22 00:46, Arnd Bergmann wrote:
> On Mon, May 16, 2022 at 3:19 PM Guenter Roeck <[e-mail]> wrote:
>> On 5/16/22 06:31, Greg KH wrote:
>>> On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote:
>>>> On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
>>>>> From: Arnd Bergmann <[e-mail]>
>>>>>
>>>>> During a patch discussion, Linus brought up the option of changing
>>>>> the C standard version from gnu89 to gnu99, which allows using variable
>>>>> declaration inside of a for() loop. While the C99, C11 and later standards
>>>>> introduce many other features, most of these are already available in
>>>>> gnu89 as GNU extensions as well.
>>>>
>>>> The downside is that backporting affected patches to older kernel branches
>>>> now fails with error messages such as
>>>>
>>>> mm/kfence/core.c: In function ‘kfence_init_pool’:
>>>> mm/kfence/core.c:595:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
>>>>
>>>> Just something to keep in mind when writing patches.
>>>
>>> I just ran across this very issue on this commit.  It's an easy fixup
>>> for 5.17.y to make this work, so I did that in my tree.  If this gets to
>>> be too much, we might need to reconsider adding c11 to older stable
>>> kernels.
>>>
>>
>> I think I'll do just that for ChromeOS; I don't want to have to deal
>> with the backports, and we are using recent compilers anyway.
> 
> I think it would be better not to have the --std=gnu11 change in the older
> stable kernels by default, as this has introduced build warnings and other
> smaller issues, as well as raising the minimum compiler version.
> 
> The users that are stuck on older kernels for some reason tend to
> overlap with those on older compilers. One example here is Android,
> which used to ship with a gcc-4.9 build as the only non-clang toolchain,
> and was using this for building their kernels. If someone wants to
> pull in stable updates into an older Android, this would fail with
> -std=gnu11. Others may be in the same situation.
> 
> Changing some of the 5.x stable branches to -std=gnu11 is probably
> less of a problem, but I would not know where to draw the line exactly.
> Maybe check with the Android team to see what the newest kernel is
> that they expect to be built with the old gcc-4.9.
> 

I don't think they still build anything with gcc. We (ChromeOS) only
need it for test builds of chromeos-4.4 (sigh), and that will hopefully
be gone in a couple of months.

We already enabled -std=gnu11 in chromeos-5.10 and chromeos-5.15.
We'll see if that is possible with chromeos-5.4 as well.
We won't bother with older kernel branches, but those should not
get many patches from upstream outside stable release merges,
so it is less of a problem.

Guenter

Patch

diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst
index ec474a70a02f..894f2a6eb9db 100644
--- a/Documentation/process/programming-language.rst
+++ b/Documentation/process/programming-language.rst
@@ -5,8 +5,8 @@  Programming Language
 
 The kernel is written in the C programming language [c-language]_.
 More precisely, the kernel is typically compiled with ``gcc`` [gcc]_
-under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90
-(including some C99 features). ``clang`` [clang]_ is also supported, see
+under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11
+(including some C17 features). ``clang`` [clang]_ is also supported, see
 docs on :ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.
 
 This dialect contains many extensions to the language [gnu-extensions]_,
diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst
index 41db2598ce11..aa21097737ae 100644
--- a/Documentation/translations/it_IT/process/programming-language.rst
+++ b/Documentation/translations/it_IT/process/programming-language.rst
@@ -10,8 +10,8 @@  Linguaggio di programmazione
 
 Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_.
 Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando
-l'opzione ``-std=gnu89`` [it-gcc-c-dialect-options]_: il dialetto GNU
-dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99).
+l'opzione ``-std=gnu11`` [it-gcc-c-dialect-options]_: il dialetto GNU
+dello standard ISO C11 (con l'aggiunta di alcune funzionalità da C17).
 Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione
 :ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.
 
diff --git a/Documentation/translations/zh_CN/process/programming-language.rst b/Documentation/translations/zh_CN/process/programming-language.rst
index 2a47a1d2ec20..58d2b3bd2d85 100644
--- a/Documentation/translations/zh_CN/process/programming-language.rst
+++ b/Documentation/translations/zh_CN/process/programming-language.rst
@@ -9,8 +9,8 @@ 
 ============
 
 内核是用C语言 :ref:`c-language <cn_c-language>` 编写的。更准确地说，内核通常是用 :ref:`gcc <cn_gcc>`
-在 ``-std=gnu89`` :ref:`gcc-c-dialect-options <cn_gcc-c-dialect-options>` 下编译的：ISO C90的 GNU 方言（
-包括一些C99特性）
+在 ``-std=gnu11`` :ref:`gcc-c-dialect-options <cn_gcc-c-dialect-options>` 下编译的：ISO C11的 GNU 方言（
+包括一些C17特性）
 
 这种方言包含对语言 :ref:`gnu-extensions <cn_gnu-extensions>` 的许多扩展，当然，它们许多都在内核中使用。
 
diff --git a/Documentation/translations/zh_TW/process/programming-language.rst b/Documentation/translations/zh_TW/process/programming-language.rst
index 54e3699eadf8..235de05f7e2c 100644
--- a/Documentation/translations/zh_TW/process/programming-language.rst
+++ b/Documentation/translations/zh_TW/process/programming-language.rst
@@ -12,8 +12,8 @@ 
 ============
 
 內核是用C語言 :ref:`c-language <tw_c-language>` 編寫的。更準確地說，內核通常是用 :ref:`gcc <tw_gcc>`
-在 ``-std=gnu89`` :ref:`gcc-c-dialect-options <tw_gcc-c-dialect-options>` 下編譯的：ISO C90的 GNU 方言（
-包括一些C99特性）
+在 ``-std=gnu11`` :ref:`gcc-c-dialect-options <tw_gcc-c-dialect-options>` 下編譯的：ISO C11的 GNU 方言（
+包括一些C17特性）
 
 這種方言包含對語言 :ref:`gnu-extensions <tw_gnu-extensions>` 的許多擴展，當然，它們許多都在內核中使用。
 
diff --git a/Makefile b/Makefile
index 289ce2be8032..66496eaeb9ec 100644
--- a/Makefile
+++ b/Makefile
@@ -432,7 +432,7 @@  HOSTCXX	= g++
 endif
 
 export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
-			      -O2 -fomit-frame-pointer -std=gnu89
+			      -O2 -fomit-frame-pointer -std=gnu11
 export KBUILD_USERLDFLAGS :=
 
 KBUILD_HOSTCFLAGS   := $(KBUILD_USERCFLAGS) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS)
@@ -515,7 +515,7 @@  KBUILD_CFLAGS   := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
 		   -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \
 		   -Werror=implicit-function-declaration -Werror=implicit-int \
 		   -Werror=return-type -Wno-format-security \
-		   -std=gnu89
+		   -std=gnu11
 KBUILD_CPPFLAGS := -D__KERNEL__
 KBUILD_AFLAGS_KERNEL :=
 KBUILD_CFLAGS_KERNEL :=
@@ -782,7 +782,7 @@  KBUILD_CFLAGS += $(KBUILD_CFLAGS-y) $(CONFIG_CC_IMPLICIT_FALLTHROUGH)
 
 ifdef CONFIG_CC_IS_CLANG
 KBUILD_CPPFLAGS += -Qunused-arguments
-# The kernel builds with '-std=gnu89' so use of GNU extensions is acceptable.
+# The kernel builds with '-std=gnu11' so use of GNU extensions is acceptable.
 KBUILD_CFLAGS += -Wno-gnu
 # CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the
 # source of a reference will be _MergedGlobals and not on of the whitelisted names.
diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
index 6c01b63ff56d..9378ea055bf2 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -68,7 +68,7 @@  VDSO_CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                -fno-strict-aliasing -fno-common \
                -Werror-implicit-function-declaration \
                -Wno-format-security \
-               -std=gnu89
+               -std=gnu11
 VDSO_CFLAGS  += -O2
 # Some useful compiler-dependent flags from top-level Makefile
 VDSO_CFLAGS += $(call cc32-option,-Wdeclaration-after-statement,)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1b62b9f65196..1618a6e0af4e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -17,6 +17,7 @@  subdir-ccflags-y += -Wno-unused-parameter
 subdir-ccflags-y += -Wno-type-limits
 subdir-ccflags-y += -Wno-missing-field-initializers
 subdir-ccflags-y += -Wno-sign-compare
+subdir-ccflags-y += -Wno-shift-negative-value
 subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
 subdir-ccflags-y += $(call cc-disable-warning, frame-address)
 subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
diff --git a/drivers/staging/greybus/tools/Makefile b/drivers/staging/greybus/tools/Makefile
index ad0ae8053b79..a3bbd73171f2 100644
--- a/drivers/staging/greybus/tools/Makefile
+++ b/drivers/staging/greybus/tools/Makefile
@@ -12,7 +12,8 @@  CFLAGS	+= -std=gnu99 -Wall -Wextra -g \
 	    -Wredundant-decls \
 	    -Wcast-align \
 	    -Wsign-compare \
-	    -Wno-missing-field-initializers
+	    -Wno-missing-field-initializers \
+	    -Wno-shift-negative-value
 
 CC	:= $(CROSS_COMPILE)gcc
 
diff --git a/fs/btrfs/Makefile b/fs/btrfs/Makefile
index 4188ba3fd8c3..99f9995670ea 100644
--- a/fs/btrfs/Makefile
+++ b/fs/btrfs/Makefile
@@ -17,6 +17,7 @@  subdir-ccflags-y += $(condflags)
 subdir-ccflags-y += -Wno-missing-field-initializers
 subdir-ccflags-y += -Wno-sign-compare
 subdir-ccflags-y += -Wno-type-limits
+subdir-ccflags-y += -Wno-shift-negative-value
 
 obj-$(CONFIG_BTRFS_FS) := btrfs.o
 
diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 8be892887d71..650d0b8ceec3 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -36,6 +36,7 @@  KBUILD_CFLAGS += $(call cc-option, -Wstringop-truncation)
 KBUILD_CFLAGS += -Wno-missing-field-initializers
 KBUILD_CFLAGS += -Wno-sign-compare
 KBUILD_CFLAGS += -Wno-type-limits
+KBUILD_CFLAGS += -Wno-shift-negative-value
 
 KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARN1