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-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> --- 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 -- 2.29.2
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-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> --- 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 -- 2.29.2
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-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> --- 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 -- 2.29.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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-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> --- 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 -- 2.29.2
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 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 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-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> > --- > 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-value > > CC := $(CROSS_COMPILE)gcc > . . .
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-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> > --- > 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-value > > CC := $(CROSS_COMPILE)gcc > . . . _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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-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> > --- > 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-value > > CC := $(CROSS_COMPILE)gcc > . . .
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-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> > --- > 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-value > > CC := $(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 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 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 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-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> > --- > 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 > > -- > 2.29.2 > -- _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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-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> > --- > 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 > > -- > 2.29.2 > --
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-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> > --- > 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 > > -- > 2.29.2 > --
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-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> > --- > 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 > > -- > 2.29.2 > --
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 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 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 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 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
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
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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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
Mark actually has a tree that switches to gnu99 with a lot of the issues already sortd out and keeping sane default for things like the absolutely horrible declarations in the middle of code here: https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=treewide/gnu99&id=697e436ae0216aef4a37e69e85042c225492d6ff 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 > 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-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> > --- > 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 > > -- > 2.29.2 > ---end quoted text---
Mark actually has a tree that switches to gnu99 with a lot of the issues already sortd out and keeping sane default for things like the absolutely horrible declarations in the middle of code here: https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=treewide/gnu99&id=697e436ae0216aef4a37e69e85042c225492d6ff 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 > 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-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> > --- > 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 > > -- > 2.29.2 > ---end quoted text---
Mark actually has a tree that switches to gnu99 with a lot of the issues already sortd out and keeping sane default for things like the absolutely horrible declarations in the middle of code here: https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=treewide/gnu99&id=697e436ae0216aef4a37e69e85042c225492d6ff 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 > 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-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> > --- > 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 > > -- > 2.29.2 > ---end quoted text--- _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
== Series Details == Series: Kbuild: remove -std=gnu89 from compiler arguments URL : https://patchwork.freedesktop.org/series/100823/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[-- Attachment #1: Type: text/plain, Size: 7138 bytes --] == Series Details == Series: Kbuild: remove -std=gnu89 from compiler arguments URL : https://patchwork.freedesktop.org/series/100823/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22434 ==================================================== Summary ------- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/index.html Participating hosts (43 -> 41) ------------------------------ Additional (1): bat-jsl-2 Missing (3): fi-bsw-cyan fi-bdw-samus fi-pnv-d510 Known issues ------------ Here are the changes found in Patchwork_22434 that come from known issues: ### IGT changes ### #### Issues hit #### * igt@amdgpu/amd_basic@cs-multi-fence: - fi-blb-e6850: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-blb-e6850/igt@amdgpu/amd_basic@cs-multi-fence.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600: NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-snb-2600/igt@amdgpu/amd_cs_nop@sync-fork-compute0.html * igt@gem_exec_suspend@basic-s3@smem: - fi-skl-6600u: [PASS][3] -> [INCOMPLETE][4] ([i915#4547]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-skl-6600u/igt@gem_exec_suspend@basic-s3@smem.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-skl-6600u/igt@gem_exec_suspend@basic-s3@smem.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: [PASS][5] -> [FAIL][6] ([i915#4032]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_pm_rps@basic-api.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-dg1-5/igt@i915_pm_rps@basic-api.html * igt@i915_selftest@live@gt_engines: - bat-dg1-6: [PASS][7] -> [INCOMPLETE][8] ([i915#4418]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-6/igt@i915_selftest@live@gt_engines.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-dg1-6/igt@i915_selftest@live@gt_engines.html * igt@runner@aborted: - bat-dg1-6: NOTRUN -> [FAIL][9] ([i915#4312]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-dg1-6/igt@runner@aborted.html #### Possible fixes #### * igt@i915_selftest@live@gt_heartbeat: - fi-glk-dsi: [DMESG-FAIL][10] ([i915#541]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600: [INCOMPLETE][12] ([i915#3921]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-snb-2600/igt@i915_selftest@live@hangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-snb-2600/igt@i915_selftest@live@hangcheck.html * igt@i915_selftest@live@requests: - fi-blb-e6850: [DMESG-FAIL][14] ([i915#5026]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@live@requests.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-blb-e6850/igt@i915_selftest@live@requests.html * igt@kms_busy@basic@modeset: - bat-adlp-4: [DMESG-WARN][16] ([i915#3576]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_busy@basic@modeset.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-adlp-4/igt@kms_busy@basic@modeset.html * igt@kms_force_connector_basic@force-connector-state: - fi-cfl-8109u: [DMESG-WARN][18] ([i915#165]) -> [PASS][19] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_basic@force-connector-state.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-cfl-8109u/igt@kms_force_connector_basic@force-connector-state.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [DMESG-WARN][20] ([i915#165] / [i915#295]) -> [PASS][21] +13 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-cfl-8109u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b.html #### Warnings #### * igt@kms_busy@basic@flip: - bat-adlp-4: [DMESG-WARN][22] ([i915#3576]) -> [DMESG-WARN][23] ([i915#1982] / [i915#3576]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_busy@basic@flip.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-adlp-4/igt@kms_busy@basic@flip.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 [i915#4032]: https://gitlab.freedesktop.org/drm/intel/issues/4032 [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898 [i915#5026]: https://gitlab.freedesktop.org/drm/intel/issues/5026 [i915#5127]: https://gitlab.freedesktop.org/drm/intel/issues/5127 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Build changes ------------- * Linux: CI_DRM_11300 -> Patchwork_22434 CI-20190529: 20190529 CI_DRM_11300: 10eb9bc8729d3da3fe8f53c8e5b70b8a9a52b6e0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6361: 2372a4beb6a33c5f0799a4a8ccbb93794f52dbca @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22434: 08ac100992340795d1f5fac8b71b7e3ab8e2b7ef @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 08ac10099234 Kbuild: remove -std=gnu89 from compiler arguments == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/index.html [-- Attachment #2: Type: text/html, Size: 7730 bytes --]
[-- Attachment #1: Type: text/plain, Size: 30273 bytes --] == Series Details == Series: Kbuild: remove -std=gnu89 from compiler arguments URL : https://patchwork.freedesktop.org/series/100823/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300_full -> Patchwork_22434_full ==================================================== Summary ------- **WARNING** Minor unknown changes coming with Patchwork_22434_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22434_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 13) ------------------------------ No changes in participating hosts Possible new issues ------------------- Here are the unknown changes that may have been introduced in Patchwork_22434_full: ### IGT changes ### #### Warnings #### * igt@kms_chamelium@hdmi-hpd-storm-disable: - shard-tglb: [SKIP][1] ([fdo#109284] / [fdo#111827]) -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-tglb2/igt@kms_chamelium@hdmi-hpd-storm-disable.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@kms_chamelium@hdmi-hpd-storm-disable.html #### Suppressed #### The following results come from untrusted machines, tests, or statuses. They do not affect the overall result. * igt@i915_pm_dc@dc6-dpms: - {shard-rkl}: [PASS][3] -> ([INCOMPLETE][4], [PASS][5]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-rkl-2/igt@i915_pm_dc@dc6-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-rkl-5/igt@i915_pm_dc@dc6-dpms.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-rkl-4/igt@i915_pm_dc@dc6-dpms.html * igt@i915_selftest@live@slpc: - {shard-rkl}: [PASS][6] -> [INCOMPLETE][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-rkl-5/igt@i915_selftest@live@slpc.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-rkl-5/igt@i915_selftest@live@slpc.html * {igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1-planes-downscale}: - shard-iclb: [PASS][8] -> [SKIP][9] +5 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-iclb5/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1-planes-downscale.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb2/igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1-planes-downscale.html * {igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5}: - {shard-rkl}: NOTRUN -> [SKIP][10] +10 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-rkl-1/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5.html * {igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-b-edp-1-scaler-with-clipping-clamping}: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-iclb4/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-b-edp-1-scaler-with-clipping-clamping.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb2/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-b-edp-1-scaler-with-clipping-clamping.html * {igt@kms_plane_scaling@upscale-with-rotation-factor-0-25@pipe-b-hdmi-a-1-upscale-with-rotation}: - {shard-dg1}: NOTRUN -> [SKIP][13] +12 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-dg1-17/igt@kms_plane_scaling@upscale-with-rotation-factor-0-25@pipe-b-hdmi-a-1-upscale-with-rotation.html New tests --------- New tests have been introduced between CI_DRM_11300_full and Patchwork_22434_full: ### New IGT tests (1) ### * igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-d-edp-1-planes-upscale-downscale: - Statuses : 1 pass(s) - Exec time: [1.28] s Known issues ------------ Here are the changes found in Patchwork_22434_full that come from known issues: ### IGT changes ### #### Issues hit #### * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +5 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-kbl6/igt@gem_ctx_isolation@preservation-s3@vcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-kbl4/igt@gem_ctx_isolation@preservation-s3@vcs0.html * igt@gem_exec_balancer@parallel-bb-first: - shard-tglb: NOTRUN -> [DMESG-WARN][16] ([i915#5076]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@gem_exec_balancer@parallel-bb-first.html * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-kbl: NOTRUN -> [DMESG-WARN][17] ([i915#5076]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-kbl7/igt@gem_exec_balancer@parallel-keep-submit-fence.html * igt@gem_exec_capture@pi@vecs0: - shard-skl: NOTRUN -> [INCOMPLETE][18] ([i915#4547]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl1/igt@gem_exec_capture@pi@vecs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#2842]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-kbl3/igt@gem_exec_fair@basic-none-solo@rcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-kbl1/igt@gem_exec_fair@basic-none-solo@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#2842]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-glk9/igt@gem_exec_fair@basic-pace-solo@rcs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-glk3/igt@gem_exec_fair@basic-pace-solo@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: NOTRUN -> [FAIL][23] ([i915#2849]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb3/igt@gem_exec_fair@basic-throttle@rcs0.html * igt@gem_exec_params@secure-non-root: - shard-iclb: NOTRUN -> [SKIP][24] ([fdo#112283]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@gem_exec_params@secure-non-root.html * igt@gem_exec_whisper@basic-contexts-forked-all: - shard-glk: [PASS][25] -> [DMESG-WARN][26] ([i915#118]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-glk1/igt@gem_exec_whisper@basic-contexts-forked-all.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-glk7/igt@gem_exec_whisper@basic-contexts-forked-all.html * igt@gem_huc_copy@huc-copy: - shard-tglb: NOTRUN -> [SKIP][27] ([i915#2190]) [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@gem_huc_copy@huc-copy.html - shard-skl: NOTRUN -> [SKIP][28] ([fdo#109271] / [i915#2190]) [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl7/igt@gem_huc_copy@huc-copy.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-tglb: NOTRUN -> [SKIP][29] ([i915#4613]) [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@gem_lmem_swapping@parallel-random-verify.html - shard-apl: NOTRUN -> [SKIP][30] ([fdo#109271] / [i915#4613]) [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl1/igt@gem_lmem_swapping@parallel-random-verify.html * igt@gem_pxp@create-regular-context-2: - shard-tglb: NOTRUN -> [SKIP][31] ([i915#4270]) [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@gem_pxp@create-regular-context-2.html * igt@gem_pxp@reject-modify-context-protection-off-3: - shard-iclb: NOTRUN -> [SKIP][32] ([i915#4270]) [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@gem_pxp@reject-modify-context-protection-off-3.html * igt@gem_render_copy@yf-tiled-to-vebox-x-tiled: - shard-iclb: NOTRUN -> [SKIP][33] ([i915#768]) [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb6/igt@gem_render_copy@yf-tiled-to-vebox-x-tiled.html * igt@gem_userptr_blits@coherency-sync: - shard-tglb: NOTRUN -> [SKIP][34] ([fdo#110542]) [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@gem_userptr_blits@coherency-sync.html * igt@gem_userptr_blits@unsync-unmap-after-close: - shard-tglb: NOTRUN -> [SKIP][35] ([i915#3297]) [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@gem_userptr_blits@unsync-unmap-after-close.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][36] -> [DMESG-WARN][37] ([i915#1436] / [i915#716]) [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-glk2/igt@gen9_exec_parse@allowed-all.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-glk8/igt@gen9_exec_parse@allowed-all.html * igt@gen9_exec_parse@allowed-single: - shard-iclb: NOTRUN -> [SKIP][38] ([i915#2856]) [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@gen9_exec_parse@allowed-single.html * igt@gen9_exec_parse@shadow-peek: - shard-tglb: NOTRUN -> [SKIP][39] ([i915#2527] / [i915#2856]) +2 similar issues [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb7/igt@gen9_exec_parse@shadow-peek.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][40] -> [FAIL][41] ([i915#454]) [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-iclb4/igt@i915_pm_dc@dc6-psr.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb4/igt@i915_pm_dc@dc6-psr.html - shard-tglb: NOTRUN -> [FAIL][42] ([i915#454]) [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@i915_pm_dc@dc6-psr.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-kbl: NOTRUN -> [SKIP][43] ([fdo#109271] / [i915#1937]) [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-kbl1/igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-tglb: [PASS][44] -> [WARN][45] ([i915#2681] / [i915#2684]) [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-tglb2/igt@i915_pm_rc6_residency@rc6-fence.html [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb7/igt@i915_pm_rc6_residency@rc6-fence.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-iclb: NOTRUN -> [WARN][46] ([i915#1804] / [i915#2684]) [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb3/igt@i915_pm_rc6_residency@rc6-idle.html * igt@i915_pm_rpm@cursor: - shard-tglb: [PASS][47] -> [INCOMPLETE][48] ([i915#2411]) [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-tglb7/igt@i915_pm_rpm@cursor.html [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb5/igt@i915_pm_rpm@cursor.html * igt@i915_pm_rpm@modeset-pc8-residency-stress: - shard-apl: NOTRUN -> [SKIP][49] ([fdo#109271]) +89 similar issues [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl8/igt@i915_pm_rpm@modeset-pc8-residency-stress.html * igt@i915_selftest@live@hangcheck: - shard-snb: [PASS][50] -> [INCOMPLETE][51] ([i915#3921]) [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-snb6/igt@i915_selftest@live@hangcheck.html [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-snb2/igt@i915_selftest@live@hangcheck.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][52] -> [INCOMPLETE][53] ([i915#5183] / [i915#5187]) [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-skl8/igt@i915_selftest@mock@requests.html [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl10/igt@i915_selftest@mock@requests.html * igt@kms_big_fb@linear-32bpp-rotate-90: - shard-iclb: NOTRUN -> [SKIP][54] ([fdo#110725] / [fdo#111614]) +1 similar issue [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb6/igt@kms_big_fb@linear-32bpp-rotate-90.html * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip: - shard-apl: NOTRUN -> [SKIP][55] ([fdo#109271] / [i915#3777]) +2 similar issues [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl8/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip: - shard-tglb: [PASS][56] -> [FAIL][57] ([i915#3743]) [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-tglb6/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb2/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html * igt@kms_big_fb@y-tiled-8bpp-rotate-90: - shard-tglb: NOTRUN -> [SKIP][58] ([fdo#111614]) [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_big_fb@y-tiled-8bpp-rotate-90.html * igt@kms_big_fb@yf-tiled-64bpp-rotate-0: - shard-tglb: NOTRUN -> [SKIP][59] ([fdo#111615]) +2 similar issues [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@kms_big_fb@yf-tiled-64bpp-rotate-0.html * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip: - shard-iclb: NOTRUN -> [SKIP][60] ([fdo#110723]) [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb6/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html * igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs: - shard-iclb: NOTRUN -> [SKIP][61] ([fdo#109278] / [i915#3886]) +2 similar issues [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb6/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs.html - shard-skl: NOTRUN -> [SKIP][62] ([fdo#109271] / [i915#3886]) [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl7/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][63] ([fdo#109271] / [i915#3886]) +2 similar issues [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl8/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_ccs: - shard-tglb: NOTRUN -> [SKIP][64] ([i915#3689]) +2 similar issues [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@kms_ccs@pipe-a-random-ccs-data-y_tiled_ccs.html * igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc: - shard-kbl: NOTRUN -> [SKIP][65] ([fdo#109271] / [i915#3886]) +1 similar issue [65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-kbl7/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html * igt@kms_ccs@pipe-c-missing-ccs-buffer-yf_tiled_ccs: - shard-tglb: NOTRUN -> [SKIP][66] ([fdo#111615] / [i915#3689]) +2 similar issues [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_ccs@pipe-c-missing-ccs-buffer-yf_tiled_ccs.html * igt@kms_chamelium@hdmi-crc-multiple: - shard-skl: NOTRUN -> [SKIP][67] ([fdo#109271] / [fdo#111827]) +4 similar issues [67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl7/igt@kms_chamelium@hdmi-crc-multiple.html * igt@kms_chamelium@hdmi-mode-timings: - shard-iclb: NOTRUN -> [SKIP][68] ([fdo#109284] / [fdo#111827]) +3 similar issues [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb6/igt@kms_chamelium@hdmi-mode-timings.html * igt@kms_chamelium@vga-hpd-enable-disable-mode: - shard-kbl: NOTRUN -> [SKIP][69] ([fdo#109271] / [fdo#111827]) +1 similar issue [69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-kbl1/igt@kms_chamelium@vga-hpd-enable-disable-mode.html * igt@kms_color@pipe-d-ctm-negative: - shard-iclb: NOTRUN -> [SKIP][70] ([fdo#109278] / [i915#1149]) [70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@kms_color@pipe-d-ctm-negative.html * igt@kms_color_chamelium@pipe-b-ctm-0-5: - shard-apl: NOTRUN -> [SKIP][71] ([fdo#109271] / [fdo#111827]) +8 similar issues [71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl8/igt@kms_color_chamelium@pipe-b-ctm-0-5.html * igt@kms_color_chamelium@pipe-d-ctm-max: - shard-tglb: NOTRUN -> [SKIP][72] ([fdo#109284] / [fdo#111827]) +2 similar issues [72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_color_chamelium@pipe-d-ctm-max.html * igt@kms_content_protection@dp-mst-lic-type-0: - shard-tglb: NOTRUN -> [SKIP][73] ([i915#3116] / [i915#3299]) [73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_content_protection@dp-mst-lic-type-0.html * igt@kms_content_protection@legacy: - shard-iclb: NOTRUN -> [SKIP][74] ([fdo#109300] / [fdo#111066]) [74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@kms_content_protection@legacy.html * igt@kms_content_protection@lic: - shard-apl: NOTRUN -> [TIMEOUT][75] ([i915#1319]) [75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl7/igt@kms_content_protection@lic.html * igt@kms_cursor_crc@pipe-a-cursor-512x170-random: - shard-iclb: NOTRUN -> [SKIP][76] ([fdo#109278] / [fdo#109279]) [76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb3/igt@kms_cursor_crc@pipe-a-cursor-512x170-random.html * igt@kms_cursor_crc@pipe-b-cursor-max-size-sliding: - shard-tglb: NOTRUN -> [SKIP][77] ([i915#3359]) [77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_cursor_crc@pipe-b-cursor-max-size-sliding.html * igt@kms_cursor_crc@pipe-c-cursor-32x32-onscreen: - shard-tglb: NOTRUN -> [SKIP][78] ([i915#3319]) [78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_cursor_crc@pipe-c-cursor-32x32-onscreen.html * igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement: - shard-kbl: NOTRUN -> [SKIP][79] ([fdo#109271]) +23 similar issues [79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-kbl1/igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement.html * igt@kms_cursor_crc@pipe-d-cursor-512x170-offscreen: - shard-tglb: NOTRUN -> [SKIP][80] ([fdo#109279] / [i915#3359]) +3 similar issues [80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_cursor_crc@pipe-d-cursor-512x170-offscreen.html * igt@kms_cursor_legacy@cursora-vs-flipb-atomic: - shard-tglb: NOTRUN -> [SKIP][81] ([fdo#109274] / [fdo#111825]) +4 similar issues [81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@kms_cursor_legacy@cursora-vs-flipb-atomic.html * igt@kms_cursor_legacy@pipe-d-single-bo: - shard-kbl: NOTRUN -> [SKIP][82] ([fdo#109271] / [i915#533]) [82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-kbl1/igt@kms_cursor_legacy@pipe-d-single-bo.html * igt@kms_dp_tiled_display@basic-test-pattern-with-chamelium: - shard-tglb: NOTRUN -> [SKIP][83] ([i915#3528]) [83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_dp_tiled_display@basic-test-pattern-with-chamelium.html * igt@kms_flip@2x-plain-flip: - shard-iclb: NOTRUN -> [SKIP][84] ([fdo#109274]) [84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb3/igt@kms_flip@2x-plain-flip.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1: - shard-skl: [PASS][85] -> [FAIL][86] ([i915#79]) [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html [86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-edp1.html * igt@kms_flip@flip-vs-suspend@a-dp1: - shard-apl: [PASS][87] -> [DMESG-WARN][88] ([i915#180]) +1 similar issue [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-apl7/igt@kms_flip@flip-vs-suspend@a-dp1.html [88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl1/igt@kms_flip@flip-vs-suspend@a-dp1.html * igt@kms_flip@plain-flip-fb-recreate@b-edp1: - shard-skl: [PASS][89] -> [FAIL][90] ([i915#2122]) [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-skl7/igt@kms_flip@plain-flip-fb-recreate@b-edp1.html [90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl4/igt@kms_flip@plain-flip-fb-recreate@b-edp1.html * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling: - shard-glk: [PASS][91] -> [FAIL][92] ([i915#4911]) [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-glk6/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html [92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling: - shard-iclb: [PASS][93] -> [SKIP][94] ([i915#3701]) +1 similar issue [93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-iclb3/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html [94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-upscaling: - shard-iclb: NOTRUN -> [SKIP][95] ([i915#2587]) [95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-upscaling.html * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt: - shard-iclb: NOTRUN -> [SKIP][96] ([fdo#109280]) +13 similar issues [96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-indfb-draw-blt: - shard-tglb: NOTRUN -> [SKIP][97] ([fdo#109280] / [fdo#111825]) +7 similar issues [97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-indfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbcpsr-farfromfence-mmap-gtt: - shard-skl: NOTRUN -> [SKIP][98] ([fdo#109271]) +38 similar issues [98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl7/igt@kms_frontbuffer_tracking@fbcpsr-farfromfence-mmap-gtt.html * igt@kms_invalid_mode@clock-too-high: - shard-tglb: NOTRUN -> [SKIP][99] ([i915#4278]) [99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_invalid_mode@clock-too-high.html * igt@kms_multipipe_modeset@basic-max-pipe-crc-check: - shard-tglb: NOTRUN -> [SKIP][100] ([i915#1839]) [100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_multipipe_modeset@basic-max-pipe-crc-check.html * igt@kms_pipe_b_c_ivb@from-pipe-c-to-b-with-3-lanes: - shard-tglb: NOTRUN -> [SKIP][101] ([fdo#109289]) +1 similar issue [101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@kms_pipe_b_c_ivb@from-pipe-c-to-b-with-3-lanes.html * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-d-frame-sequence: - shard-apl: NOTRUN -> [SKIP][102] ([fdo#109271] / [i915#533]) [102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl8/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-d-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d: - shard-skl: NOTRUN -> [SKIP][103] ([fdo#109271] / [i915#533]) [103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl7/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html * igt@kms_plane_alpha_blend@pipe-a-alpha-7efc: - shard-apl: NOTRUN -> [FAIL][104] ([fdo#108145] / [i915#265]) +1 similar issue [104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl7/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][105] -> [FAIL][106] ([fdo#108145] / [i915#265]) [105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html [106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl4/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max: - shard-skl: NOTRUN -> [FAIL][107] ([fdo#108145] / [i915#265]) [107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max.html * igt@kms_plane_alpha_blend@pipe-d-constant-alpha-max: - shard-iclb: NOTRUN -> [SKIP][108] ([fdo#109278]) +7 similar issues [108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@kms_plane_alpha_blend@pipe-d-constant-alpha-max.html * igt@kms_plane_lowres@pipe-b-tiling-yf: - shard-tglb: NOTRUN -> [SKIP][109] ([fdo#111615] / [fdo#112054]) [109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@kms_plane_lowres@pipe-b-tiling-yf.html * igt@kms_plane_lowres@pipe-c-tiling-none: - shard-tglb: NOTRUN -> [SKIP][110] ([i915#3536]) +1 similar issue [110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@kms_plane_lowres@pipe-c-tiling-none.html * igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area: - shard-iclb: NOTRUN -> [SKIP][111] ([fdo#111068] / [i915#658]) [111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb6/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html - shard-skl: NOTRUN -> [SKIP][112] ([fdo#109271] / [i915#658]) [112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl7/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html * igt@kms_psr@psr2_sprite_mmap_cpu: - shard-iclb: NOTRUN -> [SKIP][113] ([fdo#109441]) +1 similar issue [113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@kms_psr@psr2_sprite_mmap_cpu.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-tglb: NOTRUN -> [FAIL][114] ([i915#132] / [i915#3467]) [114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][115] -> [SKIP][116] ([fdo#109441]) +2 similar issues [115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_vrr@flipline: - shard-iclb: NOTRUN -> [SKIP][117] ([fdo#109502]) [117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb7/igt@kms_vrr@flipline.html * igt@kms_writeback@writeback-invalid-parameters: - shard-apl: NOTRUN -> [SKIP][118] ([fdo#109271] / [i915#2437]) [118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-apl7/igt@kms_writeback@writeback-invalid-parameters.html * igt@nouveau_crc@pipe-a-source-outp-complete: - shard-iclb: NOTRUN -> [SKIP][119] ([i915#2530]) [119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb3/igt@nouveau_crc@pipe-a-source-outp-complete.html * igt@nouveau_crc@pipe-b-source-outp-complete: - shard-tglb: NOTRUN -> [SKIP][120] ([i915#2530]) +1 similar issue [120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@nouveau_crc@pipe-b-source-outp-complete.html * igt@nouveau_crc@pipe-d-source-rg: - shard-iclb: NOTRUN -> [SKIP][121] ([fdo#109278] / [i915#2530]) [121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb6/igt@nouveau_crc@pipe-d-source-rg.html * igt@perf@polling-small-buf: - shard-skl: [PASS][122] -> [FAIL][123] ([i915#1722]) [122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-skl4/igt@perf@polling-small-buf.html [123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-skl6/igt@perf@polling-small-buf.html * igt@prime_nv_api@i915_nv_double_import: - shard-tglb: NOTRUN -> [SKIP][124] ([fdo#109291]) +1 similar issue [124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb3/igt@prime_nv_api@i915_nv_double_import.html * igt@prime_nv_api@i915_self_import_to_different_fd: - shard-iclb: NOTRUN -> [SKIP][125] ([fdo#109291]) +2 similar issues [125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb3/igt@prime_nv_api@i915_self_import_to_different_fd.html * igt@prime_vgem@fence-write-hang: - shard-iclb: NOTRUN -> [SKIP][126] ([fdo#109295]) [126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb3/igt@prime_vgem@fence-write-hang.html * igt@sysfs_clients@pidname: - shard-iclb: NOTRUN -> [SKIP][127] ([i915#2994]) +1 similar issue [127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/index.html [-- Attachment #2: Type: text/html, Size: 33719 bytes --]