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 gnu89, 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.
Nathan Chancellor reported an additional -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround.
Since the differences between gnu99, gnu11 and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables, the easiest way is to just leave out the -std=gnu89 argument entirely, and rely on the compiler default language setting, which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported versions of gcc or clang.
Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVF... 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 --- I put the suggestion into patch form, based on what we discussed in the thread. I only gave it minimal testing, but it would be good to have it in linux-next if we want to do this in the merge window. --- 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 | 7 +++---- arch/arm64/kernel/vdso32/Makefile | 3 +-- 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(+), 15 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..3ff6ba766f02 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 export KBUILD_USERLDFLAGS :=
KBUILD_HOSTCFLAGS := $(KBUILD_USERCFLAGS) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS) @@ -514,8 +514,7 @@ KBUILD_AFLAGS := -D__ASSEMBLY__ -fno-PIE 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 + -Werror=return-type -Wno-format-security KBUILD_CPPFLAGS := -D__KERNEL__ KBUILD_AFLAGS_KERNEL := KBUILD_CFLAGS_KERNEL := @@ -782,7 +781,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..3250d0e25782 100644 --- a/arch/arm64/kernel/vdso32/Makefile +++ b/arch/arm64/kernel/vdso32/Makefile @@ -67,8 +67,7 @@ VDSO_CFLAGS += -DENABLE_COMPAT_VDSO=1 VDSO_CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -Werror-implicit-function-declaration \ - -Wno-format-security \ - -std=gnu89 + -Wno-format-security 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 Sun, Feb 27, 2022 at 1:54 PM Arnd Bergmann arnd@kernel.org wrote:
Since the differences between gnu99, gnu11 and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables, the easiest way is to just leave out the -std=gnu89 argument entirely, and rely on the compiler default language setting, which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported versions of gcc or clang.
Honestly, I'd rather keep the C version we support as some explicit thing, instead of "whatever the installed compiler is".
Not only do I suspect that you can set it in gcc spec files (so the standard version might actually be site-specific, not compiler version specific), but particularly with clang, I'd like that "GNU extensions enabled" to be explicit. Yes, maybe it's the default, but let's make sure.
The C version level has traditionally had a lot of odd semantic meaning details - you mention "inline", others have existed. So it's not just the actual new features that some C version implements, it's those kind of "same syntax, different meaning" issues. I really don't think that's something we want in the kernel any more.
Been there, done that, and we did the explicit standards level for a reason.
It may be true that c99/c11/c17 are all very similar, and don't have those issues. Or maybe they do.
And I don't want somebody with a newer compiler version to not notice that he or she ended up using a c17 feature, just because _that_ compiler supported it, and then other people get build errors because their compilers use gnu11 instead by default.
Put another way: I see absolutely no upside to allowing different users using higher/lower versions of the standard. There are only downsides.
If gnu11 is supported by gcc-5.1 and up, and all the relevant clang versions, then let's just pick that.
And if there are any possible future advantages to gnu17 (or eventual gnu2x versions), let's document those, so that we can say "once our compiler version requirements go up sufficiently, we'll move to gnuXX because we want to take advantage of YY".
Please?
Linus
Linus
On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds torvalds@linux-foundation.org wrote:
And I don't want somebody with a newer compiler version to not notice that he or she ended up using a c17 feature, just because _that_ compiler supported it, and then other people get build errors because their compilers use gnu11 instead by default.
Put another way: I see absolutely no upside to allowing different users using higher/lower versions of the standard. There are only downsides.
If gnu11 is supported by gcc-5.1 and up, and all the relevant clang versions, then let's just pick that.
Ok, changed my patch to -gnu11 now.
And if there are any possible future advantages to gnu17 (or eventual gnu2x versions), let's document those, so that we can say "once our compiler version requirements go up sufficiently, we'll move to gnuXX because we want to take advantage of YY".
Please?
I think all of the options here are equally bad: picking gnu11 means we use a non-standard default for anything other than gcc-5 and may get surprised again in the future when we want to change to a newer version; -std=gnu1x would work as an alias for gnu17 in all versions including gcc-5 but is already marked as 'deprecated' in the gcc documentation; and using -std=gnu17 for modern compilers requires a workaround for gcc-7 and earlier.
Regarding new features from gcc-2x, I think we already use most of what is listed in https://en.wikipedia.org/wiki/C2x, as those are all GNU extensions that are valid in modern gnu89 as well. Newly added features seem to only depend on the compiler version, e.g. #elifdef works in both clang-13 and gcc-12 with any -std=gnu?? argument, so picking an earlier standard won't stop people from breaking the build with older compilers.
Arnd
On 2/27/22 3:52 PM, 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 gnu89, 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.
Nathan Chancellor reported an additional -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround.
Since the differences between gnu99, gnu11 and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables, the easiest way is to just leave out the -std=gnu89 argument entirely, and rely on the compiler default language setting, which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported versions of gcc or clang.
Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVF... 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
I put the suggestion into patch form, based on what we discussed in the thread. I only gave it minimal testing, but it would be good to have it in linux-next if we want to do this in the merge window.
Did you determine what needed the new compiler flag based on compilation results?
Glancing at the Greybus code, I don't believe there's any reason it needs to shift a negative value. Such warnings could be fixed by making certain variables unsigned, for example.
I have no objection, I'll just make a note of it.
-Alex
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 | 7 +++---- arch/arm64/kernel/vdso32/Makefile | 3 +-- 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(+), 15 deletions(-)
. . .
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-valueCC := $(CROSS_COMPILE)gcc
. . .
On Sun, Feb 27, 2022 at 3:04 PM Alex Elder elder@linaro.org wrote:
Glancing at the Greybus code, I don't believe there's any reason it needs to shift a negative value. Such warnings could be fixed by making certain variables unsigned, for example.
As mentioned in the original thread, making things unsigned actually is likely to introduce bugs and make things worse.
The warning is simply bogus, and the fact that it was enabled by -Wextra in gcc for std=gnu99 and up was a mistake that looks likely to be fixed in gcc.
So don't try to "fix" the code to make any possible warnings go away. You may just make things worse.
(That is often true in general for the more esoteric warnings, but in this case it's just painfully more obvious).
Linus
On 2/27/22 5:11 PM, Linus Torvalds wrote:
On Sun, Feb 27, 2022 at 3:04 PM Alex Elder elder@linaro.org wrote:
Glancing at the Greybus code, I don't believe there's any reason it needs to shift a negative value. Such warnings could be fixed by making certain variables unsigned, for example.
As mentioned in the original thread, making things unsigned actually is likely to introduce bugs and make things worse.
Understood. What I meant is that the shifts were producing single-bit masks from plain int values that range from 0 to 10 or something (in a for loop). Looking again though, that it's not so simple. Regardless, your point about the warning is good and I won't plan to "fix" this.
Thanks.
-Alex
The warning is simply bogus, and the fact that it was enabled by -Wextra in gcc for std=gnu99 and up was a mistake that looks likely to be fixed in gcc.
So don't try to "fix" the code to make any possible warnings go away. You may just make things worse.
(That is often true in general for the more esoteric warnings, but in this case it's just painfully more obvious).
Linus
On Mon, Feb 28, 2022 at 12:04 AM Alex Elder elder@linaro.org wrote:
On 2/27/22 3:52 PM, Arnd Bergmann wrote: From: Arnd Bergmann arnd@arndb.de
I put the suggestion into patch form, based on what we discussed in the thread. I only gave it minimal testing, but it would be good to have it in linux-next if we want to do this in the merge window.
Did you determine what needed the new compiler flag based on compilation results?
Glancing at the Greybus code, I don't believe there's any reason it needs to shift a negative value. Such warnings could be fixed by making certain variables unsigned, for example.
I have no objection, I'll just make a note of it.
I've clarified in the changelog that I'm adding the -Wno-shift-negative-value everywhere that -Wextra is used, not because I saw actual warnings for greybus and btrfs. The -Wextra is copied from scripts/Makefile.extrawarn, so this keeps it in sync. Ideally we should have an easier way for a subdirectory to get the W=1 flags without copying the list, but the patch I started to do this never got close to getting integrated.
Arnd
On Sun, Feb 27, 2022 at 10:52:43PM +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 gnu89, but this was taken care of by defining 'inline' to
Typo here? Second one should be gnu99 right?
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.
Nathan Chancellor reported an additional -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround.
Since the differences between gnu99, gnu11 and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables, the easiest way is to just leave out the -std=gnu89 argument entirely, and rely on the compiler default language setting, which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported versions of gcc or clang.
Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVF... 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
I put the suggestion into patch form, based on what we discussed in the thread. I only gave it minimal testing, but it would be good to have it in linux-next if we want to do this in the merge window.
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 | 7 +++---- arch/arm64/kernel/vdso32/Makefile | 3 +-- 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(+), 15 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..3ff6ba766f02 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-pointerexport KBUILD_USERLDFLAGS :=
KBUILD_HOSTCFLAGS := $(KBUILD_USERCFLAGS) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS) @@ -514,8 +514,7 @@ KBUILD_AFLAGS := -D__ASSEMBLY__ -fno-PIE 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
-Werror=return-type -Wno-format-securityKBUILD_CPPFLAGS := -D__KERNEL__ KBUILD_AFLAGS_KERNEL := KBUILD_CFLAGS_KERNEL := @@ -782,7 +781,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..3250d0e25782 100644 --- a/arch/arm64/kernel/vdso32/Makefile +++ b/arch/arm64/kernel/vdso32/Makefile @@ -67,8 +67,7 @@ VDSO_CFLAGS += -DENABLE_COMPAT_VDSO=1 VDSO_CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -Werror-implicit-function-declaration \
-Wno-format-security \-std=gnu89
-Wno-format-securityVDSO_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-valueCC := $(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 1:14 AM John Stoffel john@quad.stoffel.home wrote:
On Sun, Feb 27, 2022 at 10:52:43PM +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 gnu89, but this was taken care of by defining 'inline' to
Typo here? Second one should be gnu99 right?
Fixed, thanks!
Arnd
dri-devel@lists.freedesktop.org
-
Alex Elder -
Arnd Bergmann -
John Stoffel -
Linus Torvalds