| Message ID | 20220228103142.3301082-1-arnd@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] Kbuild: move to -std=gnu11 | expand |
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > 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-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Masahiro Yamada <masahiroy@kernel.org> > Cc: linux-kbuild@vger.kernel.org > Cc: llvm@lists.linux.dev > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > [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(-) For the greybus tools section: Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hi Arnd, This is great! On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > 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 Thanks, Mark. > 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-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Masahiro Yamada <masahiroy@kernel.org> > Cc: linux-kbuild@vger.kernel.org > Cc: llvm@lists.linux.dev > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > [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(-) > > 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 > > -- > 2.29.2 >
On Mon, Feb 28, 2022 at 12:25 PM Mark Rutland <mark.rutland@arm.com> wrote: > On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > > > > 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 think the KBUILD_USERCFLAGS portion and the modpost.c fix for it make sense regardless of the -std=gnu11 change, but your change to KBUILD_CFLAGS is not actually needed because the warning is already enabled there -- gnu89 allows intermingled declarations since gcc-3.4, so the warning flag was added during early 2.6.x kernels. Arnd
On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > 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. 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. > 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-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Masahiro Yamada <masahiroy@kernel.org> > Cc: linux-kbuild@vger.kernel.org > Cc: llvm@lists.linux.dev > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Marco Elver <elver@google.com> Thanks, -- Marco > --- > [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(-) > > 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 > > -- > 2.29.2 > >
On Mon, Feb 28, 2022 at 12:47 PM Marco Elver <elver@google.com> wrote: > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann <arnd@kernel.org> 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-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > > Cc: Masahiro Yamada <masahiroy@kernel.org> > > Cc: linux-kbuild@vger.kernel.org > > Cc: llvm@lists.linux.dev > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > Acked-by: Marco Elver <elver@google.com> Thanks, Arnd
On Mon, 28 Feb 2022, Arnd Bergmann <arnd@kernel.org> wrote: > From: Arnd Bergmann <arnd@arndb.de> > > 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. Do you mean always enable -Wall and/or -Wextra instead of -Werror? We do use -Werror for our CI and development too, but it's hidden behind a config option that depends on COMPILE_TEST=n to avoid any problems with allmodconfig/allyesconfig. For the future, makes me wonder if we couldn't have a way for drivers to locally enable -Wall/-Wextra in a way that incorporates the exceptions from kbuild instead of having to duplicate them. Anyway, for the i915 changes, Acked-by: Jani Nikula <jani.nikula@intel.com> > > 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-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Masahiro Yamada <masahiroy@kernel.org> > Cc: linux-kbuild@vger.kernel.org > Cc: llvm@lists.linux.dev > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > [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(-) > > 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
On Mon, Feb 28, 2022 at 6:32 PM Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > 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-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Masahiro Yamada <masahiroy@kernel.org> > Cc: linux-kbuild@vger.kernel.org > Cc: llvm@lists.linux.dev > Signed-off-by: Arnd Bergmann <arnd@arndb.de> For document part, Reviewed-by: Alex Shi <alexs@kernel.org> > --- > [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(-) > > 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 > > -- > 2.29.2 >
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > > Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Masahiro Yamada <masahiroy@kernel.org> > Cc: linux-kbuild@vger.kernel.org > Cc: llvm@lists.linux.dev > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > [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 ++- For > fs/btrfs/Makefile | 1 + Acked-by: David Sterba <dsterba@suse.com>
On Mon, Feb 28, 2022 at 1:36 PM Jani Nikula <jani.nikula@linux.intel.com> wrote: > > > > 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. > > Do you mean always enable -Wall and/or -Wextra instead of -Werror? > > We do use -Werror for our CI and development too, but it's hidden behind > a config option that depends on COMPILE_TEST=n to avoid any problems > with allmodconfig/allyesconfig. What I meant here is that I'm adding -Wno-shift-negative-value to all four places in the kernel that already use -Wextra. > For the future, makes me wonder if we couldn't have a way for drivers to > locally enable -Wall/-Wextra in a way that incorporates the exceptions > from kbuild instead of having to duplicate them. I have an older patch series that does this, but it also does a few other things that I couldn't quite get right in the end with all combinations of compiler versions and warning levels, so I did not submit that. What this allows is to have per-directory statements like KBUILD_WARN1=1 KBUILD_ERROR0=1 to force all the default warnings (-Wall etc) to be errors, while making the W=1 type warnings (-Wextra etc) normal warnings. > Anyway, for the i915 changes, > > Acked-by: Jani Nikula <jani.nikula@intel.com> Thanks, Arnd
On Mon, Feb 28, 2022 at 02:01:06PM +0100, Arnd Bergmann wrote: > On Mon, Feb 28, 2022 at 1:36 PM Jani Nikula <jani.nikula@linux.intel.com> wrote: > > > > > > 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. > > > > Do you mean always enable -Wall and/or -Wextra instead of -Werror? > > > > We do use -Werror for our CI and development too, but it's hidden behind > > a config option that depends on COMPILE_TEST=n to avoid any problems > > with allmodconfig/allyesconfig. > > What I meant here is that I'm adding -Wno-shift-negative-value to all > four places in the kernel that already use -Wextra. > > > For the future, makes me wonder if we couldn't have a way for drivers to > > locally enable -Wall/-Wextra in a way that incorporates the exceptions > > from kbuild instead of having to duplicate them. > > I have an older patch series that does this, but it also does a few other > things that I couldn't quite get right in the end with all combinations of > compiler versions and warning levels, so I did not submit that. > > What this allows is to have per-directory statements like > > KBUILD_WARN1=1 We've added the individual warnings to the per-directory flags so it's a bit more flexible than just enabling W=1. The idea is to add possibly stricter warnings once we make sure it builds fine and does not produce false reports. Extending W=1 in the same way would affect everybody.
On Mon, Feb 28, 2022 at 12:57:55PM +0100, Arnd Bergmann wrote: > On Mon, Feb 28, 2022 at 12:47 PM Marco Elver <elver@google.com> wrote: > > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann <arnd@kernel.org> 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-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > > > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > > > Cc: Masahiro Yamada <masahiroy@kernel.org> > > > Cc: linux-kbuild@vger.kernel.org > > > Cc: llvm@lists.linux.dev > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > > > > Acked-by: Marco Elver <elver@google.com> Cheers, Nathan
On Mon, Feb 28, 2022 at 7:32 PM Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > 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 <masahiroy@kernel.org> Please let me know if you want me to pick up this. -- Best Regards Masahiro Yamada
On Mon, Feb 28, 2022 at 8:25 PM Mark Rutland <mark.rutland@arm.com> wrote: > > Hi Arnd, > > This is great! > > On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > > > 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?
On Mon, Feb 28, 2022 at 6:02 PM Masahiro Yamada <masahiroy@kernel.org> wrote: > > On Mon, Feb 28, 2022 at 7:32 PM Arnd Bergmann <arnd@kernel.org> wrote: > > > > From: Arnd Bergmann <arnd@arndb.de> > > > > 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 <masahiroy@kernel.org> > > > 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
On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann <arnd@kernel.org> 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
On Mon, Feb 28, 2022 at 2:32 AM Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > 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 <ndesaulniers@google.com> > > Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> > Cc: Masahiro Yamada <masahiroy@kernel.org> > Cc: linux-kbuild@vger.kernel.org > Cc: llvm@lists.linux.dev > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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 <arnd@kernel.org> wrote: >> >> From: Arnd Bergmann <arnd@arndb.de> >> >> 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 <ndesaulniers@google.com> > >> >> Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ >> Link: https://github.com/ClangBuiltLinux/linux/issues/1603 >> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> >> Cc: Masahiro Yamada <masahiroy@kernel.org> >> Cc: linux-kbuild@vger.kernel.org >> Cc: llvm@lists.linux.dev >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> > >-- >Thanks, >~Nick Desaulniers >
On Mon, Feb 28, 2022 at 11:32 AM Arnd Bergmann <arnd@kernel.org> 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 <ojeda@kernel.org> Cheers, Miguel
On Tue, Mar 1, 2022 at 11:43 AM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Mon, Feb 28, 2022 at 11:32 AM Arnd Bergmann <arnd@kernel.org> 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 <ojeda@kernel.org> Thanks.
On Mon, Feb 28, 2022 at 10:41 PM Fangrui Song <maskray@google.com> 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
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > 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
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 <arnd@arndb.de> > > > > 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
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 <arnd@arndb.de> >>> >>> 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
On Mon, May 16, 2022 at 3:19 PM Guenter Roeck <linux@roeck-us.net> 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 <arnd@arndb.de> > >>> > >>> 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. Arnd
On 5/18/22 00:46, Arnd Bergmann wrote: > On Mon, May 16, 2022 at 3:19 PM Guenter Roeck <linux@roeck-us.net> 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 <arnd@arndb.de> >>>>> >>>>> 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
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