All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fangrui Song <maskray@google.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
	linux-kbuild@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, Jonathan Corbet <corbet@lwn.net>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Alex Shi <alexs@kernel.org>, Hu Haowen <src.res@email.cn>,
	Michal Marek <michal.lkml@markovi.net>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-doc-tw-discuss@lists.sourceforge.net,
	linux-arm-kernel@lists.infradead.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 13:41:45 -0800	[thread overview]
Message-ID: <20220228214145.o37bgp3zl3rxpeo4@google.com> (raw)
In-Reply-To: <CAKwvOdkLUx1td+qgUYy3w2ojtBG-mJTzpJg3BV8Xv56YHTxHCw@mail.gmail.com>

Thanks for the patch!

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

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

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

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

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

Agree this is handled by

     #define inline inline __gnu_inline __inline_maybe_unused notrace

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

WARNING: multiple messages have this Message-ID (diff)
From: Fangrui Song <maskray@google.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
	linux-kbuild@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, Jonathan Corbet <corbet@lwn.net>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Alex Shi <alexs@kernel.org>, Hu Haowen <src.res@email.cn>,
	Michal Marek <michal.lkml@markovi.net>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-doc-tw-discuss@lists.sourceforge.net,
	linux-arm-kernel@lists.infradead.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	greybus-dev@lists.linaro.org, linux-staging@lists.linux.dev,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 13:41:45 -0800	[thread overview]
Message-ID: <20220228214145.o37bgp3zl3rxpeo4@google.com> (raw)
In-Reply-To: <CAKwvOdkLUx1td+qgUYy3w2ojtBG-mJTzpJg3BV8Xv56YHTxHCw@mail.gmail.com>

Thanks for the patch!

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

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

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

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

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

Agree this is handled by

     #define inline inline __gnu_inline __inline_maybe_unused notrace

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Fangrui Song <maskray@google.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kbuild@vger.kernel.org, linux-staging@lists.linux.dev,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	greybus-dev@lists.linaro.org,
	linux-arm-kernel@lists.infradead.org,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Hu Haowen <src.res@email.cn>,
	intel-gfx@lists.freedesktop.org, Jonathan Corbet <corbet@lwn.net>,
	linux-btrfs@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	Alex Shi <alexs@kernel.org>
Subject: Re: [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 13:41:45 -0800	[thread overview]
Message-ID: <20220228214145.o37bgp3zl3rxpeo4@google.com> (raw)
In-Reply-To: <CAKwvOdkLUx1td+qgUYy3w2ojtBG-mJTzpJg3BV8Xv56YHTxHCw@mail.gmail.com>

Thanks for the patch!

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

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

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

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

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

Agree this is handled by

     #define inline inline __gnu_inline __inline_maybe_unused notrace

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

WARNING: multiple messages have this Message-ID (diff)
From: Fangrui Song <maskray@google.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Arnd Bergmann <arnd@kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kbuild@vger.kernel.org, linux-staging@lists.linux.dev,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	greybus-dev@lists.linaro.org,
	linux-arm-kernel@lists.infradead.org,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Hu Haowen <src.res@email.cn>,
	intel-gfx@lists.freedesktop.org, Jonathan Corbet <corbet@lwn.net>,
	linux-btrfs@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	Alex Shi <alexs@kernel.org>
Subject: Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
Date: Mon, 28 Feb 2022 13:41:45 -0800	[thread overview]
Message-ID: <20220228214145.o37bgp3zl3rxpeo4@google.com> (raw)
In-Reply-To: <CAKwvOdkLUx1td+qgUYy3w2ojtBG-mJTzpJg3BV8Xv56YHTxHCw@mail.gmail.com>

Thanks for the patch!

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

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

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

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

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

Agree this is handled by

     #define inline inline __gnu_inline __inline_maybe_unused notrace

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

  reply	other threads:[~2022-02-28 21:41 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 10:27 [PATCH] [v2] Kbuild: move to -std=gnu11 Arnd Bergmann
2022-02-28 10:27 ` [Intel-gfx] " Arnd Bergmann
2022-02-28 10:27 ` Arnd Bergmann
2022-02-28 10:27 ` Arnd Bergmann
2022-02-28 10:50 ` Greg KH
2022-02-28 10:50   ` Greg KH
2022-02-28 10:50   ` [Intel-gfx] " Greg KH
2022-02-28 10:50   ` Greg KH
2022-02-28 11:25 ` Mark Rutland
2022-02-28 11:25   ` [Intel-gfx] " Mark Rutland
2022-02-28 11:25   ` Mark Rutland
2022-02-28 11:25   ` Mark Rutland
2022-02-28 11:37   ` Arnd Bergmann
2022-02-28 11:37     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 11:37     ` Arnd Bergmann
2022-02-28 11:37     ` Arnd Bergmann
2022-02-28 18:40     ` [Intel-gfx] " Linus Torvalds
2022-02-28 18:40       ` Linus Torvalds
2022-02-28 18:40       ` Linus Torvalds
2022-02-28 18:40       ` Linus Torvalds
2022-02-28 17:07   ` Masahiro Yamada
2022-02-28 17:07     ` [Intel-gfx] " Masahiro Yamada
2022-02-28 17:07     ` Masahiro Yamada
2022-02-28 17:07     ` Masahiro Yamada
2022-02-28 11:47 ` Marco Elver
2022-02-28 11:47   ` [Intel-gfx] " Marco Elver
2022-02-28 11:47   ` Marco Elver
2022-02-28 11:47   ` Marco Elver
2022-02-28 11:57   ` Arnd Bergmann
2022-02-28 11:57     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 11:57     ` Arnd Bergmann
2022-02-28 11:57     ` Arnd Bergmann
2022-02-28 16:56     ` Nathan Chancellor
2022-02-28 16:56       ` [Intel-gfx] " Nathan Chancellor
2022-02-28 16:56       ` Nathan Chancellor
2022-02-28 16:56       ` Nathan Chancellor
2022-02-28 12:36 ` Jani Nikula
2022-02-28 12:36   ` Jani Nikula
2022-02-28 12:36   ` [Intel-gfx] " Jani Nikula
2022-02-28 12:36   ` Jani Nikula
2022-02-28 13:01   ` Arnd Bergmann
2022-02-28 13:01     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 13:01     ` Arnd Bergmann
2022-02-28 13:01     ` Arnd Bergmann
2022-02-28 13:19     ` David Sterba
2022-02-28 13:19       ` David Sterba
2022-02-28 13:19       ` [Intel-gfx] " David Sterba
2022-02-28 13:19       ` David Sterba
2022-02-28 12:48 ` Alex Shi
2022-02-28 12:48   ` Alex Shi
2022-02-28 12:48   ` [Intel-gfx] " Alex Shi
2022-02-28 12:48   ` Alex Shi
2022-02-28 12:56 ` David Sterba
2022-02-28 12:56   ` David Sterba
2022-02-28 12:56   ` [Intel-gfx] " David Sterba
2022-02-28 12:56   ` David Sterba
2022-02-28 17:02 ` Masahiro Yamada
2022-02-28 17:02   ` [Intel-gfx] " Masahiro Yamada
2022-02-28 17:02   ` Masahiro Yamada
2022-02-28 17:02   ` Masahiro Yamada
2022-02-28 18:24   ` Arnd Bergmann
2022-02-28 18:24     ` [Intel-gfx] " Arnd Bergmann
2022-02-28 18:24     ` Arnd Bergmann
2022-02-28 18:24     ` Arnd Bergmann
2022-02-28 21:03 ` Nick Desaulniers
2022-02-28 21:03   ` Nick Desaulniers
2022-02-28 21:03   ` [Intel-gfx] " Nick Desaulniers
2022-02-28 21:03   ` Nick Desaulniers
2022-02-28 21:41   ` Fangrui Song [this message]
2022-02-28 21:41     ` [Intel-gfx] " Fangrui Song
2022-02-28 21:41     ` Fangrui Song
2022-02-28 21:41     ` Fangrui Song
2022-03-01 14:45     ` Arnd Bergmann
2022-03-01 14:45       ` [Intel-gfx] " Arnd Bergmann
2022-03-01 14:45       ` Arnd Bergmann
2022-03-01 14:45       ` Arnd Bergmann
2022-02-28 21:41 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2022-02-28 22:13 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-01  7:30 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-03-01 10:24 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Kbuild: move to -std=gnu11 (rev2) Patchwork
2022-03-01 10:43 ` [PATCH] [v2] Kbuild: move to -std=gnu11 Miguel Ojeda
2022-03-01 10:43   ` [Intel-gfx] " Miguel Ojeda
2022-03-01 10:43   ` Miguel Ojeda
2022-03-01 10:43   ` Miguel Ojeda
2022-03-01 14:44   ` Arnd Bergmann
2022-03-01 14:44     ` [Intel-gfx] " Arnd Bergmann
2022-03-01 14:44     ` Arnd Bergmann
2022-03-01 14:44     ` Arnd Bergmann
2022-03-01 10:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success for Kbuild: move to -std=gnu11 (rev2) Patchwork
2022-03-01 17:22 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-05-16 13:10 ` [PATCH] [v2] Kbuild: move to -std=gnu11 Guenter Roeck
2022-05-16 13:10   ` Guenter Roeck
2022-05-16 13:10   ` [Intel-gfx] " Guenter Roeck
2022-05-16 13:10   ` Guenter Roeck
2022-05-16 13:31   ` [greybus-dev] " Greg KH
2022-05-16 13:31     ` Greg KH
2022-05-16 13:31     ` [Intel-gfx] " Greg KH
2022-05-16 13:31     ` Greg KH
2022-05-16 14:19     ` Guenter Roeck
2022-05-16 14:19       ` Guenter Roeck
2022-05-16 14:19       ` [Intel-gfx] " Guenter Roeck
2022-05-16 14:19       ` Guenter Roeck
2022-05-18  7:46       ` Arnd Bergmann
2022-05-18  7:46         ` Arnd Bergmann
2022-05-18  7:46         ` Arnd Bergmann
2022-05-18 14:07         ` Guenter Roeck
2022-05-18 14:07           ` Guenter Roeck
2022-05-18 14:07           ` [Intel-gfx] " Guenter Roeck
2022-05-18 14:07           ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220228214145.o37bgp3zl3rxpeo4@google.com \
    --to=maskray@google.com \
    --cc=alexs@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=federico.vaga@vaga.pv.it \
    --cc=greybus-dev@lists.linaro.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-doc-tw-discuss@lists.sourceforge.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=ndesaulniers@google.com \
    --cc=src.res@email.cn \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.