Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > During a patch discussion, Linus brought up the option of changing > the C standard version from gnu89 to gnu99, which allows using variable > declaration inside of a for() loop. While the C99, C11 and later standards > introduce many other features, most of these are already available in > gnu89 as GNU extensions as well. The downside is that backporting affected patches to older kernel branches now fails with error messages such as mm/kfence/core.c: In function ‘kfence_init_pool’: mm/kfence/core.c:595:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode Just something to keep in mind when writing patches. Guenter
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 11:32 AM Arnd Bergmann wrote: > > -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 > -(including some C99 features). ``clang`` [clang]_ is also supported, see > +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 > +(including some C17 features). ``clang`` [clang]_ is also supported, see I think the "(including some C17)" bit would not make much sense anymore. There were no major changes in C17 and GCC implements `-std=c11` and `-std=c17` as basically the same thing according to the docs (and GNU extensions apply equally to both, I would assume). When I wrote the "(including some C99 features)" I meant that GCC implemented some C99 features as extensions in C90 mode, and the kernel used some of those (e.g. the now gone VLAs). With that changed, for `programming-language.rst`: Reviewed-by: Miguel Ojeda Cheers, Miguel
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 10:41 PM Fangrui Song wrote: > > > >More precisely, the semantics of "extern inline" functions changed > >between ISO C90 and ISO C99. > > Perhaps a clearer explanation to readers is: "extern inline" and "inline" swap > semantics with gnu_inline (-fgnu89-inline or __attribute__((__gnu_inline__))). > > >That's the only concern I have, which I doubt is an issue. The kernel > >is already covered by the function attribute as you note. > > > >Just to have some measure: > >$ git grep -rn "extern inline" | wc -l > >116 > > "^inline" behaves like C99+ "extern inline" > > Agree this is handled by > > #define inline inline __gnu_inline __inline_maybe_unused notrace > Ok, I've reworded it again, but kept it a bit shorter, I don't think we need the full explanation in this patch description in the end. Thanks, Arnd
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Tue, Mar 1, 2022 at 11:43 AM Miguel Ojeda wrote: > > On Mon, Feb 28, 2022 at 11:32 AM Arnd Bergmann wrote: > > > > -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 > > -(including some C99 features). ``clang`` [clang]_ is also supported, see > > +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 > > +(including some C17 features). ``clang`` [clang]_ is also supported, see > > I think the "(including some C17)" bit would not make much sense > anymore. There were no major changes in C17 and GCC implements > `-std=c11` and `-std=c17` as basically the same thing according to the > docs (and GNU extensions apply equally to both, I would assume). Ok, changed now. > When I wrote the "(including some C99 features)" I meant that GCC > implemented some C99 features as extensions in C90 mode, and the > kernel used some of those (e.g. the now gone VLAs). I suppose it's still true for some c2x features (static_assert, fallthrough, binary literals, ...), but it seems easier to just leave it out. > With that changed, for `programming-language.rst`: > > Reviewed-by: Miguel Ojeda Thanks.
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 6:02 PM Masahiro Yamada wrote: > > On Mon, Feb 28, 2022 at 7:32 PM Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > During a patch discussion, Linus brought up the option of changing > > the C standard version from gnu89 to gnu99, which allows using variable > > declaration inside of a for() loop. While the C99, C11 and later standards > > introduce many other features, most of these are already available in > > gnu89 as GNU extensions as well. > > > > An earlier attempt to do this when gcc-5 started defaulting to > > -std=gnu11 failed because at the time that caused warnings about > > designated initializers with older compilers. Now that gcc-5.1 is the > > minimum compiler version used for building kernels, that is no longer a > > concern. Similarly, the behavior of 'inline' functions changes between > > gnu89 and gnu11, but this was taken care of by defining 'inline' to > > include __attribute__((gnu_inline)) in order to allow building with > > clang a while ago. > > > > One minor issue that remains is an added gcc warning for shifts of > > negative integers when building with -Werror, which happens with the > > Is this a typo? > >building with -Werror, ... > -> >building with -Wextra, ... > I'm being slow today, Jani actually pointed out the same thing and I misunderstood him. Fixed it now, thanks! > Acked-by: Masahiro Yamada > > > Please let me know if you want me to pick up this. Yes, that would be great. I'll send a v3 with the updated changelog, but will drop most of the Cc list as there are no functional changes. Arnd
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 7:32 PM Arnd Bergmann wrote: > > From: Arnd Bergmann > > During a patch discussion, Linus brought up the option of changing > the C standard version from gnu89 to gnu99, which allows using variable > declaration inside of a for() loop. While the C99, C11 and later standards > introduce many other features, most of these are already available in > gnu89 as GNU extensions as well. > > An earlier attempt to do this when gcc-5 started defaulting to > -std=gnu11 failed because at the time that caused warnings about > designated initializers with older compilers. Now that gcc-5.1 is the > minimum compiler version used for building kernels, that is no longer a > concern. Similarly, the behavior of 'inline' functions changes between > gnu89 and gnu11, but this was taken care of by defining 'inline' to > include __attribute__((gnu_inline)) in order to allow building with > clang a while ago. > > One minor issue that remains is an added gcc warning for shifts of > negative integers when building with -Werror, which happens with the Is this a typo? building with -Werror, ... -> building with -Wextra, ... > 'make W=1' option, as well as for three drivers in the kernel that always > enable -Werror, but it was only observed with the i915 driver so far. Same here. enable -Werror, but ... -> enable -Wextra, but ... Otherwise, Acked-by: Masahiro Yamada Please let me know if you want me to pick up this. -- Best Regards Masahiro Yamada
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 12:57:55PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote:
> > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote:
> >
> > > Nathan Chancellor reported an additional -Wdeclaration-after-statement
> > > warning that appears in a system header on arm, this still needs a
> > > workaround.
> >
> > On the topic of Wdeclaration-after-statement, Clang only respects this
> > warning with C99 and later starting with Clang 14:
> > https://github.com/llvm/llvm-project/commit/c65186c89f35#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97R61
> >
> > Until Clang 14, -Wdeclaration-after-statement is ignored by Clang in
> > newer standards. If this is a big problem, we can probably convince
> > the Clang stable folks to backport the fixes. However, the build won't
> > fail, folks might just miss the warning if they don't also test with
> > GCC.
Unfortunately, none of the branches prior to release/14.x are going to
see any more updates (at least as far as I am aware, as the LLVM
community only supports one release branch at a time) but as Arnd
mentioned below, I do not really see that as a problem, as newer
versions of clang and GCC will catch these warnings.
> I don't expect this is to be a big issue, as long as the latest clang behaves
> as expected. There are many warnings that are only produced by one of the
> two compilers, so this is something we already deal with.
>
> I think it's more important to address the extra warning that Nathan
> reported, where clang now complains about the intermingled declaration
> in a system header when previously neither gcc nor clang noticed this.
Right. Based on the upstream LLVM bug, I think we should just fix
arm_neon.h to avoid triggering -Wdeclaration-after-statement to have
something that is (hopefully) relatively low risk for a clang-14
backport, rather than addressing the root cause of clang warning in
system macros, as it sounds like fixing that has some risks that are not
fully understood at this point. The kernel only uses very specific
system headers after commit 04e85bbf71c9 ("isystem: delete global
-isystem compile option"), so I don't think that my suggested approach
will have many downsides.
I think I see how to potentially fix arm_neon.h in
clang/utils/TableGen/NeonEmitter.cpp, I just have to think about it a
little more.
Realistically, I don't think special casing this in lib/raid6 is the end
of the world:
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 45e17619422b..a41ff71b90af 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -38,6 +38,10 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
NEON_FLAGS := -ffreestanding
# Enable
NEON_FLAGS += -isystem $(shell $(CC) -print-file-name=include)
+# https://github.com/ClangBuiltLinux/linux/issues/1603
+ifeq ($(CONFIG_CC_IS_CLANG)$(CONFIG_CPU_BIG_ENDIAN),yy)
+NEON_FLAGS += -Wno-declaration-after-statement
+endif
ifeq ($(ARCH),arm)
NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
endif
> > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly
> > > minimal and mainly impact warnings at the -Wpedantic level that the
> > > kernel never enables. Between these, gnu11 is the newest version
> > > that is supported by all supported compiler versions, though it is
> > > only the default on gcc-5, while all other supported versions of
> > > gcc or clang default to gnu1x/gnu17.
> > >
> > > Link:
> > > https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603
> > > Suggested-by: Linus Torvalds
> > > Cc: Masahiro Yamada
> > > Cc: linux-kbu...@vger.kernel.org
> > > Cc: l...@lists.linux.dev
> > > Signed-off-by: Arnd Bergmann
> >
> > Acked-by: Marco Elver
Cheers,
Nathan
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 8:25 PM Mark Rutland wrote: > > Hi Arnd, > > This is great! > > On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > During a patch discussion, Linus brought up the option of changing > > the C standard version from gnu89 to gnu99, which allows using variable > > declaration inside of a for() loop. While the C99, C11 and later standards > > introduce many other features, most of these are already available in > > gnu89 as GNU extensions as well. > > > > An earlier attempt to do this when gcc-5 started defaulting to > > -std=gnu11 failed because at the time that caused warnings about > > designated initializers with older compilers. Now that gcc-5.1 is the > > minimum compiler version used for building kernels, that is no longer a > > concern. Similarly, the behavior of 'inline' functions changes between > > gnu89 and gnu11, but this was taken care of by defining 'inline' to > > include __attribute__((gnu_inline)) in order to allow building with > > clang a while ago. > > > > One minor issue that remains is an added gcc warning for shifts of > > negative integers when building with -Werror, which happens with the > > 'make W=1' option, as well as for three drivers in the kernel that always > > enable -Werror, but it was only observed with the i915 driver so far. > > To be on the safe side, add -Wno-shift-negative-value to any -Wextra > > in a Makefile. > > > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > > warning that appears in a system header on arm, this still needs a > > workaround. > > FWIW, I had a go at moving to c99 a few weeks ago (to be able to use > for-loop-declarations in some concurrency primitives), and when I tried, I > also > saw declaration-after-statement warnings when building modpost.c, which is > easy > enough to fix: > > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=treewide/gnu99&id=505775bd6fd0bc1883f3271f826963066bbdc194 > I do not understand this statement: "Usually such warnings are implciitly enabled as part of `-std=gnu89`, and in preparation for changing the standard used, this patch explciitly enales the warnings with `-Wdeclaration-after-statement`, which takes effect regardless of which version of the C standard is in use." modpost is already built with -std=gnu89. If Wdeclaration-after-statement is implied by gnu89, why did nobody notice this before? -- Best Regards Masahiro Yamada
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann wrote: > > I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it > make sense regardless of the -std=gnu11 change I do think they make sense, but I want to note again that people doing cross builds obviously use different tools for user builds than for the kernel. In fact, even not cross-building, we've had situations where the "kbuild" compiler is different from the host compiler, because people have upgraded one but not the other (upgrading the kernel build environment is actually much easier than upgrading the host build environment, because you don't need all the random libraries etc, and you can literally _just_ build your own gcc and binutils) And we have *not* necessarily required that the host tools match the kernel tools. So I could well imagine that there are people who build their kernels, but their host build environment might be old enough that -std=gnu11 is problematic for that part. And note how any change to KBUILD_USERCFLAGS is reflected in KBUILD_HOSTCFLAGS. So I would suggest that the KBUILD_USERCFLAGS part of the patch (and the modpost.c change that goes with it) be done as a separate commit. Because we might end up reverting that part. Hmm? Linus
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote: > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote: > > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > > warning that appears in a system header on arm, this still needs a > > workaround. > > On the topic of Wdeclaration-after-statement, Clang only respects this > warning with C99 and later starting with Clang 14: > https://github.com/llvm/llvm-project/commit/c65186c89f35#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97R61 > > Until Clang 14, -Wdeclaration-after-statement is ignored by Clang in > newer standards. If this is a big problem, we can probably convince > the Clang stable folks to backport the fixes. However, the build won't > fail, folks might just miss the warning if they don't also test with > GCC. I don't expect this is to be a big issue, as long as the latest clang behaves as expected. There are many warnings that are only produced by one of the two compilers, so this is something we already deal with. I think it's more important to address the extra warning that Nathan reported, where clang now complains about the intermingled declaration in a system header when previously neither gcc nor clang noticed this. > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > > minimal and mainly impact warnings at the -Wpedantic level that the > > kernel never enables. Between these, gnu11 is the newest version > > that is supported by all supported compiler versions, though it is > > only the default on gcc-5, while all other supported versions of > > gcc or clang default to gnu1x/gnu17. > > > > Link: > > https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > > Suggested-by: Linus Torvalds > > Cc: Masahiro Yamada > > Cc: linux-kbu...@vger.kernel.org > > Cc: l...@lists.linux.dev > > Signed-off-by: Arnd Bergmann > > Acked-by: Marco Elver Thanks, Arnd
[Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
From: Arnd Bergmann During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already available in gnu89 as GNU extensions as well. An earlier attempt to do this when gcc-5 started defaulting to -std=gnu11 failed because at the time that caused warnings about designated initializers with older compilers. Now that gcc-5.1 is the minimum compiler version used for building kernels, that is no longer a concern. Similarly, the behavior of 'inline' functions changes between gnu89 and gnu11, but this was taken care of by defining 'inline' to include __attribute__((gnu_inline)) in order to allow building with clang a while ago. One minor issue that remains is an added gcc warning for shifts of negative integers when building with -Werror, which happens with the 'make W=1' option, as well as for three drivers in the kernel that always enable -Werror, but it was only observed with the i915 driver so far. To be on the safe side, add -Wno-shift-negative-value to any -Wextra in a Makefile. Nathan Chancellor reported an additional -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround. The differences between gnu99, gnu11, gnu1x and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables. Between these, gnu11 is the newest version that is supported by all supported compiler versions, though it is only the default on gcc-5, while all other supported versions of gcc or clang default to gnu1x/gnu17. Link: https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ Link: https://github.com/ClangBuiltLinux/linux/issues/1603 Suggested-by: Linus Torvalds Cc: Masahiro Yamada Cc: linux-kbu...@vger.kernel.org Cc: l...@lists.linux.dev Signed-off-by: Arnd Bergmann --- [v2] - added -std=gnu11 back, rather than just relying on the default - minor changes to changelog text --- Documentation/process/programming-language.rst | 4 ++-- .../translations/it_IT/process/programming-language.rst | 4 ++-- .../translations/zh_CN/process/programming-language.rst | 4 ++-- .../translations/zh_TW/process/programming-language.rst | 4 ++-- Makefile| 6 +++--- arch/arm64/kernel/vdso32/Makefile | 2 +- drivers/gpu/drm/i915/Makefile | 1 + drivers/staging/greybus/tools/Makefile | 3 ++- fs/btrfs/Makefile | 1 + scripts/Makefile.extrawarn | 1 + 10 files changed, 17 insertions(+), 13 deletions(-) diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst index ec474a70a02f..894f2a6eb9db 100644 --- a/Documentation/process/programming-language.rst +++ b/Documentation/process/programming-language.rst @@ -5,8 +5,8 @@ Programming Language The kernel is written in the C programming language [c-language]_. More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 -(including some C99 features). ``clang`` [clang]_ is also supported, see +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 +(including some C17 features). ``clang`` [clang]_ is also supported, see docs on :ref:`Building Linux with Clang/LLVM `. 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 `. 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 @
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 1:36 PM Jani Nikula wrote: > > > > One minor issue that remains is an added gcc warning for shifts of > > negative integers when building with -Werror, which happens with the > > 'make W=1' option, as well as for three drivers in the kernel that always > > enable -Werror, but it was only observed with the i915 driver so far. > > To be on the safe side, add -Wno-shift-negative-value to any -Wextra > > in a Makefile. > > Do you mean always enable -Wall and/or -Wextra instead of -Werror? > > We do use -Werror for our CI and development too, but it's hidden behind > a config option that depends on COMPILE_TEST=n to avoid any problems > with allmodconfig/allyesconfig. What I meant here is that I'm adding -Wno-shift-negative-value to all four places in the kernel that already use -Wextra. > For the future, makes me wonder if we couldn't have a way for drivers to > locally enable -Wall/-Wextra in a way that incorporates the exceptions > from kbuild instead of having to duplicate them. I have an older patch series that does this, but it also does a few other things that I couldn't quite get right in the end with all combinations of compiler versions and warning levels, so I did not submit that. What this allows is to have per-directory statements like KBUILD_WARN1=1 KBUILD_ERROR0=1 to force all the default warnings (-Wall etc) to be errors, while making the W=1 type warnings (-Wextra etc) normal warnings. > Anyway, for the i915 changes, > > Acked-by: Jani Nikula Thanks, Arnd
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
Hi Arnd, This is great! On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > During a patch discussion, Linus brought up the option of changing > the C standard version from gnu89 to gnu99, which allows using variable > declaration inside of a for() loop. While the C99, C11 and later standards > introduce many other features, most of these are already available in > gnu89 as GNU extensions as well. > > An earlier attempt to do this when gcc-5 started defaulting to > -std=gnu11 failed because at the time that caused warnings about > designated initializers with older compilers. Now that gcc-5.1 is the > minimum compiler version used for building kernels, that is no longer a > concern. Similarly, the behavior of 'inline' functions changes between > gnu89 and gnu11, but this was taken care of by defining 'inline' to > include __attribute__((gnu_inline)) in order to allow building with > clang a while ago. > > One minor issue that remains is an added gcc warning for shifts of > negative integers when building with -Werror, which happens with the > 'make W=1' option, as well as for three drivers in the kernel that always > enable -Werror, but it was only observed with the i915 driver so far. > To be on the safe side, add -Wno-shift-negative-value to any -Wextra > in a Makefile. > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > warning that appears in a system header on arm, this still needs a > workaround. FWIW, I had a go at moving to c99 a few weeks ago (to be able to use for-loop-declarations in some concurrency primitives), and when I tried, I also saw declaration-after-statement warnings when building modpost.c, which is easy enough to fix: https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=treewide/gnu99&id=505775bd6fd0bc1883f3271f826963066bbdc194 Thanks, Mark. > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > minimal and mainly impact warnings at the -Wpedantic level that the > kernel never enables. Between these, gnu11 is the newest version > that is supported by all supported compiler versions, though it is > only the default on gcc-5, while all other supported versions of > gcc or clang default to gnu1x/gnu17. > > Link: > https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds > Cc: Masahiro Yamada > Cc: linux-kbu...@vger.kernel.org > Cc: l...@lists.linux.dev > Signed-off-by: Arnd Bergmann > --- > [v2] > - added -std=gnu11 back, rather than just relying on the default > - minor changes to changelog text > --- > Documentation/process/programming-language.rst | 4 ++-- > .../translations/it_IT/process/programming-language.rst | 4 ++-- > .../translations/zh_CN/process/programming-language.rst | 4 ++-- > .../translations/zh_TW/process/programming-language.rst | 4 ++-- > Makefile| 6 +++--- > arch/arm64/kernel/vdso32/Makefile | 2 +- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/staging/greybus/tools/Makefile | 3 ++- > fs/btrfs/Makefile | 1 + > scripts/Makefile.extrawarn | 1 + > 10 files changed, 17 insertions(+), 13 deletions(-) > > diff --git a/Documentation/process/programming-language.rst > b/Documentation/process/programming-language.rst > index ec474a70a02f..894f2a6eb9db 100644 > --- a/Documentation/process/programming-language.rst > +++ b/Documentation/process/programming-language.rst > @@ -5,8 +5,8 @@ Programming Language > > The kernel is written in the C programming language [c-language]_. > More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ > -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 > -(including some C99 features). ``clang`` [clang]_ is also supported, see > +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 > +(including some C17 features). ``clang`` [clang]_ is also supported, see > docs on :ref:`Building Linux with Clang/LLVM `. > > 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 > -de
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 6:32 PM Arnd Bergmann wrote: > > From: Arnd Bergmann > > During a patch discussion, Linus brought up the option of changing > the C standard version from gnu89 to gnu99, which allows using variable > declaration inside of a for() loop. While the C99, C11 and later standards > introduce many other features, most of these are already available in > gnu89 as GNU extensions as well. > > An earlier attempt to do this when gcc-5 started defaulting to > -std=gnu11 failed because at the time that caused warnings about > designated initializers with older compilers. Now that gcc-5.1 is the > minimum compiler version used for building kernels, that is no longer a > concern. Similarly, the behavior of 'inline' functions changes between > gnu89 and gnu11, but this was taken care of by defining 'inline' to > include __attribute__((gnu_inline)) in order to allow building with > clang a while ago. > > One minor issue that remains is an added gcc warning for shifts of > negative integers when building with -Werror, which happens with the > 'make W=1' option, as well as for three drivers in the kernel that always > enable -Werror, but it was only observed with the i915 driver so far. > To be on the safe side, add -Wno-shift-negative-value to any -Wextra > in a Makefile. > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > warning that appears in a system header on arm, this still needs a > workaround. > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > minimal and mainly impact warnings at the -Wpedantic level that the > kernel never enables. Between these, gnu11 is the newest version > that is supported by all supported compiler versions, though it is > only the default on gcc-5, while all other supported versions of > gcc or clang default to gnu1x/gnu17. > > Link: > https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds > Cc: Masahiro Yamada > Cc: linux-kbu...@vger.kernel.org > Cc: l...@lists.linux.dev > Signed-off-by: Arnd Bergmann For document part, Reviewed-by: Alex Shi > --- > [v2] > - added -std=gnu11 back, rather than just relying on the default > - minor changes to changelog text > --- > Documentation/process/programming-language.rst | 4 ++-- > .../translations/it_IT/process/programming-language.rst | 4 ++-- > .../translations/zh_CN/process/programming-language.rst | 4 ++-- > .../translations/zh_TW/process/programming-language.rst | 4 ++-- > Makefile| 6 +++--- > arch/arm64/kernel/vdso32/Makefile | 2 +- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/staging/greybus/tools/Makefile | 3 ++- > fs/btrfs/Makefile | 1 + > scripts/Makefile.extrawarn | 1 + > 10 files changed, 17 insertions(+), 13 deletions(-) > > diff --git a/Documentation/process/programming-language.rst > b/Documentation/process/programming-language.rst > index ec474a70a02f..894f2a6eb9db 100644 > --- a/Documentation/process/programming-language.rst > +++ b/Documentation/process/programming-language.rst > @@ -5,8 +5,8 @@ Programming Language > > The kernel is written in the C programming language [c-language]_. > More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ > -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 > -(including some C99 features). ``clang`` [clang]_ is also supported, see > +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 > +(including some C17 features). ``clang`` [clang]_ is also supported, see > docs on :ref:`Building Linux with Clang/LLVM `. > > 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 `. > > diff --git > a/Documentation/translations/zh_CN/process/pr
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 12:25 PM Mark Rutland wrote: > On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > > > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > > warning that appears in a system header on arm, this still needs a > > workaround. > > FWIW, I had a go at moving to c99 a few weeks ago (to be able to use > for-loop-declarations in some concurrency primitives), and when I tried, I > also > saw declaration-after-statement warnings when building modpost.c, which is > easy > enough to fix: > > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h=treewide/gnu99&id=505775bd6fd0bc1883f3271f826963066bbdc194 I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it make sense regardless of the -std=gnu11 change, but your change to KBUILD_CFLAGS is not actually needed because the warning is already enabled there -- gnu89 allows intermingled declarations since gcc-3.4, so the warning flag was added during early 2.6.x kernels. Arnd
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 02:01:06PM +0100, Arnd Bergmann wrote: > On Mon, Feb 28, 2022 at 1:36 PM Jani Nikula > wrote: > > > > > > One minor issue that remains is an added gcc warning for shifts of > > > negative integers when building with -Werror, which happens with the > > > 'make W=1' option, as well as for three drivers in the kernel that always > > > enable -Werror, but it was only observed with the i915 driver so far. > > > To be on the safe side, add -Wno-shift-negative-value to any -Wextra > > > in a Makefile. > > > > Do you mean always enable -Wall and/or -Wextra instead of -Werror? > > > > We do use -Werror for our CI and development too, but it's hidden behind > > a config option that depends on COMPILE_TEST=n to avoid any problems > > with allmodconfig/allyesconfig. > > What I meant here is that I'm adding -Wno-shift-negative-value to all > four places in the kernel that already use -Wextra. > > > For the future, makes me wonder if we couldn't have a way for drivers to > > locally enable -Wall/-Wextra in a way that incorporates the exceptions > > from kbuild instead of having to duplicate them. > > I have an older patch series that does this, but it also does a few other > things that I couldn't quite get right in the end with all combinations of > compiler versions and warning levels, so I did not submit that. > > What this allows is to have per-directory statements like > > KBUILD_WARN1=1 We've added the individual warnings to the per-directory flags so it's a bit more flexible than just enabling W=1. The idea is to add possibly stricter warnings once we make sure it builds fine and does not produce false reports. Extending W=1 in the same way would affect everybody.
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > > Link: > https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds > Cc: Masahiro Yamada > Cc: linux-kbu...@vger.kernel.org > Cc: l...@lists.linux.dev > Signed-off-by: Arnd Bergmann > --- > [v2] > - added -std=gnu11 back, rather than just relying on the default > - minor changes to changelog text > --- > Documentation/process/programming-language.rst | 4 ++-- > .../translations/it_IT/process/programming-language.rst | 4 ++-- > .../translations/zh_CN/process/programming-language.rst | 4 ++-- > .../translations/zh_TW/process/programming-language.rst | 4 ++-- > Makefile| 6 +++--- > arch/arm64/kernel/vdso32/Makefile | 2 +- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/staging/greybus/tools/Makefile | 3 ++- For > fs/btrfs/Makefile | 1 + Acked-by: David Sterba
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, 28 Feb 2022, Arnd Bergmann wrote: > From: Arnd Bergmann > > During a patch discussion, Linus brought up the option of changing > the C standard version from gnu89 to gnu99, which allows using variable > declaration inside of a for() loop. While the C99, C11 and later standards > introduce many other features, most of these are already available in > gnu89 as GNU extensions as well. > > An earlier attempt to do this when gcc-5 started defaulting to > -std=gnu11 failed because at the time that caused warnings about > designated initializers with older compilers. Now that gcc-5.1 is the > minimum compiler version used for building kernels, that is no longer a > concern. Similarly, the behavior of 'inline' functions changes between > gnu89 and gnu11, but this was taken care of by defining 'inline' to > include __attribute__((gnu_inline)) in order to allow building with > clang a while ago. > > One minor issue that remains is an added gcc warning for shifts of > negative integers when building with -Werror, which happens with the > 'make W=1' option, as well as for three drivers in the kernel that always > enable -Werror, but it was only observed with the i915 driver so far. > To be on the safe side, add -Wno-shift-negative-value to any -Wextra > in a Makefile. Do you mean always enable -Wall and/or -Wextra instead of -Werror? We do use -Werror for our CI and development too, but it's hidden behind a config option that depends on COMPILE_TEST=n to avoid any problems with allmodconfig/allyesconfig. For the future, makes me wonder if we couldn't have a way for drivers to locally enable -Wall/-Wextra in a way that incorporates the exceptions from kbuild instead of having to duplicate them. Anyway, for the i915 changes, Acked-by: Jani Nikula > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > warning that appears in a system header on arm, this still needs a > workaround. > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > minimal and mainly impact warnings at the -Wpedantic level that the > kernel never enables. Between these, gnu11 is the newest version > that is supported by all supported compiler versions, though it is > only the default on gcc-5, while all other supported versions of > gcc or clang default to gnu1x/gnu17. > > Link: > https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds > Cc: Masahiro Yamada > Cc: linux-kbu...@vger.kernel.org > Cc: l...@lists.linux.dev > Signed-off-by: Arnd Bergmann > --- > [v2] > - added -std=gnu11 back, rather than just relying on the default > - minor changes to changelog text > --- > Documentation/process/programming-language.rst | 4 ++-- > .../translations/it_IT/process/programming-language.rst | 4 ++-- > .../translations/zh_CN/process/programming-language.rst | 4 ++-- > .../translations/zh_TW/process/programming-language.rst | 4 ++-- > Makefile| 6 +++--- > arch/arm64/kernel/vdso32/Makefile | 2 +- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/staging/greybus/tools/Makefile | 3 ++- > fs/btrfs/Makefile | 1 + > scripts/Makefile.extrawarn | 1 + > 10 files changed, 17 insertions(+), 13 deletions(-) > > diff --git a/Documentation/process/programming-language.rst > b/Documentation/process/programming-language.rst > index ec474a70a02f..894f2a6eb9db 100644 > --- a/Documentation/process/programming-language.rst > +++ b/Documentation/process/programming-language.rst > @@ -5,8 +5,8 @@ Programming Language > > The kernel is written in the C programming language [c-language]_. > More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ > -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 > -(including some C99 features). ``clang`` [clang]_ is also supported, see > +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 > +(including some C17 features). ``clang`` [clang]_ is also supported, see > docs on :ref:`Building Linux with Clang/LLVM `. > > 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
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > During a patch discussion, Linus brought up the option of changing > the C standard version from gnu89 to gnu99, which allows using variable > declaration inside of a for() loop. While the C99, C11 and later standards > introduce many other features, most of these are already available in > gnu89 as GNU extensions as well. > > An earlier attempt to do this when gcc-5 started defaulting to > -std=gnu11 failed because at the time that caused warnings about > designated initializers with older compilers. Now that gcc-5.1 is the > minimum compiler version used for building kernels, that is no longer a > concern. Similarly, the behavior of 'inline' functions changes between > gnu89 and gnu11, but this was taken care of by defining 'inline' to > include __attribute__((gnu_inline)) in order to allow building with > clang a while ago. > > One minor issue that remains is an added gcc warning for shifts of > negative integers when building with -Werror, which happens with the > 'make W=1' option, as well as for three drivers in the kernel that always > enable -Werror, but it was only observed with the i915 driver so far. > To be on the safe side, add -Wno-shift-negative-value to any -Wextra > in a Makefile. > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > warning that appears in a system header on arm, this still needs a > workaround. > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > minimal and mainly impact warnings at the -Wpedantic level that the > kernel never enables. Between these, gnu11 is the newest version > that is supported by all supported compiler versions, though it is > only the default on gcc-5, while all other supported versions of > gcc or clang default to gnu1x/gnu17. > > Link: > https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds > Cc: Masahiro Yamada > Cc: linux-kbu...@vger.kernel.org > Cc: l...@lists.linux.dev > Signed-off-by: Arnd Bergmann > --- > [v2] > - added -std=gnu11 back, rather than just relying on the default > - minor changes to changelog text > --- > Documentation/process/programming-language.rst | 4 ++-- > .../translations/it_IT/process/programming-language.rst | 4 ++-- > .../translations/zh_CN/process/programming-language.rst | 4 ++-- > .../translations/zh_TW/process/programming-language.rst | 4 ++-- > Makefile| 6 +++--- > arch/arm64/kernel/vdso32/Makefile | 2 +- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/staging/greybus/tools/Makefile | 3 ++- > fs/btrfs/Makefile | 1 + > scripts/Makefile.extrawarn | 1 + > 10 files changed, 17 insertions(+), 13 deletions(-) For the greybus tools section: Reviewed-by: Greg Kroah-Hartman
