Hi all,

The kernel enabled '-fms-extensions' in commit c4781dc3d1cf ("Kbuild:
enable -fms-extensions") in 6.19 to gain access to a Microsoft
(originally Plan 9) extension around including a tagged structure/union
anonymously in an other structure/union. Since then, Clang 23.0.0
(current main) has added a flag to enable only that extension, rather
than all Microsoft extensions, '-fms-anonymous-structs' [1]. Using this
narrower compiler option would have avoided the build error fixed by
commit a6773e6932cb ("jfs: Rename _inline to avoid conflict with clang's
'-fms-extensions'"). While these errors are not expected to be common,
using the narrower option when available has no drawbacks because the
kernel only cares about this extension in '-fms-extensions', no others.
While this could result in build errors for folks using
'-fms-anonymous-structs' if a developer uses another extension in
'-fms-extensions' (either intentionally or unintentionally), flagging
these uses for further scrutiny seems worthwhile.

This series converts the build system to use that flag when it is
available. The first patch consolidates all of the C dialect flags into
a single variable to make future updates to the dialect flags less
painful, as updating the logic in every place that uses their custom
built C flags is getting cumbersome (and C23 is looming). The second
patch makes the actual switch.

I would like Nicolas to carry this in the Kbuild tree for 7.1, please
provide Acks as necessary.

[1]: https://github.com/llvm/llvm-project/commit/c391efe6fb67329d8e2fd231692cc6b0ea902956

---
Nathan Chancellor (2):
      kbuild: Consolidate C dialect options
      kbuild: Use '-fms-anonymous-structs' if it is available

 Makefile                              | 16 ++++++++++++----
 arch/arm64/kernel/vdso32/Makefile     |  3 +--
 arch/loongarch/vdso/Makefile          |  2 +-
 arch/parisc/boot/compressed/Makefile  |  2 +-
 arch/powerpc/boot/Makefile            |  3 +--
 arch/s390/Makefile                    |  3 +--
 arch/s390/purgatory/Makefile          |  3 +--
 arch/x86/Makefile                     |  6 +-----
 arch/x86/boot/compressed/Makefile     |  6 +-----
 drivers/firmware/efi/libstub/Makefile |  3 +--
 init/Kconfig                          |  5 +++++
 scripts/Makefile.warn                 |  5 -----
 12 files changed, 26 insertions(+), 31 deletions(-)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260223-fms-anonymous-structs-f6ade6c8b5a6

Best regards,
--  
Nathan Chancellor <nathan@kernel.org>

On Mon, 23 Feb 2026 12:10:27 -0700, Nathan Chancellor wrote:
> The kernel enabled '-fms-extensions' in commit c4781dc3d1cf ("Kbuild:
> enable -fms-extensions") in 6.19 to gain access to a Microsoft
> (originally Plan 9) extension around including a tagged structure/union
> anonymously in an other structure/union. Since then, Clang 23.0.0
> (current main) has added a flag to enable only that extension, rather
> than all Microsoft extensions, '-fms-anonymous-structs' [1]. Using this
> narrower compiler option would have avoided the build error fixed by
> commit a6773e6932cb ("jfs: Rename _inline to avoid conflict with clang's
> '-fms-extensions'"). While these errors are not expected to be common,
> using the narrower option when available has no drawbacks because the
> kernel only cares about this extension in '-fms-extensions', no others.
> While this could result in build errors for folks using
> '-fms-anonymous-structs' if a developer uses another extension in
> '-fms-extensions' (either intentionally or unintentionally), flagging
> these uses for further scrutiny seems worthwhile.
> 
> [...]

Applied to kbuild/kbuild-next.git (kbuild-next), thanks!

[1/2] kbuild: Consolidate C dialect options
      https://git.kernel.org/kbuild/c/ec4c2827
[2/2] kbuild: Use '-fms-anonymous-structs' if it is available
      https://git.kernel.org/kbuild/c/0d3fccf6

Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped,
reverted or modified (e.g. trailers).

Acks from arch maintainers are still welcome!

Best regards,
-- 
Nicolas

On Mon, 23 Feb 2026 12:10:27 -0700, Nathan Chancellor wrote:
> The kernel enabled '-fms-extensions' in commit c4781dc3d1cf ("Kbuild:
> enable -fms-extensions") in 6.19 to gain access to a Microsoft
> (originally Plan 9) extension around including a tagged structure/union
> anonymously in an other structure/union. Since then, Clang 23.0.0
> (current main) has added a flag to enable only that extension, rather
> than all Microsoft extensions, '-fms-anonymous-structs' [1]. Using this
> narrower compiler option would have avoided the build error fixed by
> commit a6773e6932cb ("jfs: Rename _inline to avoid conflict with clang's
> '-fms-extensions'"). While these errors are not expected to be common,
> using the narrower option when available has no drawbacks because the
> kernel only cares about this extension in '-fms-extensions', no others.
> While this could result in build errors for folks using
> '-fms-anonymous-structs' if a developer uses another extension in
> '-fms-extensions' (either intentionally or unintentionally), flagging
> these uses for further scrutiny seems worthwhile.
> 
> [...]

Applied to kbuild/linux.git (kbuild-next-unstable), thanks!

[1/2] kbuild: Consolidate C dialect options
      https://git.kernel.org/kbuild/c/f3fead1c
[2/2] kbuild: Use '-fms-anonymous-structs' if it is available
      https://git.kernel.org/kbuild/c/c14d8386

Acks and review trailers are still welcome!

Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped,
reverted or modified (e.g. trailers). Patches applied to the
kbuild-next-unstable branch are accepted pending wider testing in
linux-next and any post-commit review; they will generally be moved
to the kbuild-next branch in about a week if no issues are found.

Best regards,
-- 
Nicolas

On 2026-02-23 11:10, Nathan Chancellor wrote:
> Hi all,
> 
> The kernel enabled '-fms-extensions' in commit c4781dc3d1cf ("Kbuild:
> enable -fms-extensions") in 6.19 to gain access to a Microsoft
> (originally Plan 9) extension around including a tagged structure/union
> anonymously in an other structure/union. Since then, Clang 23.0.0
> (current main) has added a flag to enable only that extension, rather
> than all Microsoft extensions, '-fms-anonymous-structs' [1]. Using this
> narrower compiler option would have avoided the build error fixed by
> commit a6773e6932cb ("jfs: Rename _inline to avoid conflict with clang's
> '-fms-extensions'"). While these errors are not expected to be common,
> using the narrower option when available has no drawbacks because the
> kernel only cares about this extension in '-fms-extensions', no others.
> While this could result in build errors for folks using
> '-fms-anonymous-structs' if a developer uses another extension in
> '-fms-extensions' (either intentionally or unintentionally), flagging
> these uses for further scrutiny seems worthwhile.
> 
> This series converts the build system to use that flag when it is
> available. The first patch consolidates all of the C dialect flags into
> a single variable to make future updates to the dialect flags less
> painful, as updating the logic in every place that uses their custom
> built C flags is getting cumbersome (and C23 is looming). The second
> patch makes the actual switch.
> 
> I would like Nicolas to carry this in the Kbuild tree for 7.1, please
> provide Acks as necessary.
> 
> [1]: https://github.com/llvm/llvm-project/commit/c391efe6fb67329d8e2fd231692cc6b0ea902956
> 

Question: does clang allow this with __extension__, or only if the option is
on the command line?  It would be desirable in the long run if both clang and
gcc would allow this with __extension__, as that would be required to use it
in uapi headers (at least without some doable-but-nontrivial preprocessing,
which might be worthwhile to do anyway...)

	-hpa

On Thu, Mar 05, 2026 at 03:43:29PM -0800, H. Peter Anvin wrote:
> Question: does clang allow this with __extension__, or only if the option is
> on the command line?  It would be desirable in the long run if both clang and

It looks like only on the command line:

  https://godbolt.org/z/zrE766obe

> gcc would allow this with __extension__, as that would be required to use it
> in uapi headers (at least without some doable-but-nontrivial preprocessing,
> which might be worthwhile to do anyway...)

I agree that would be desirable but wouldn't that change how
__extension__ works? As far as I can tell from reading GCC's
documentation [1], __extension__ just supresses warnings from -pedantic
and such, it does not actually enable a used extension if it conflicts
with whatever -std= value is passed?

[1]: https://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html

Cheers,
Nathan

On 2026-03-06 15:17, Nathan Chancellor wrote:
> On Thu, Mar 05, 2026 at 03:43:29PM -0800, H. Peter Anvin wrote:
>> Question: does clang allow this with __extension__, or only if the option is
>> on the command line?  It would be desirable in the long run if both clang and
> 
> It looks like only on the command line:
> 
>   https://godbolt.org/z/zrE766obe
> 
>> gcc would allow this with __extension__, as that would be required to use it
>> in uapi headers (at least without some doable-but-nontrivial preprocessing,
>> which might be worthwhile to do anyway...)
> 
> I agree that would be desirable but wouldn't that change how
> __extension__ works? As far as I can tell from reading GCC's
> documentation [1], __extension__ just supresses warnings from -pedantic
> and such, it does not actually enable a used extension if it conflicts
> with whatever -std= value is passed?
> 
> [1]: https://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html
> 

Maybe it does, but it's explicit purpose is to allow code to be compiled with
a -std= setting lower than the system libraries.

I was a little surprised to see that -std=c90 doesn't actually enforce C90
compatibility; even with -Wall -Wextra it requires -pedantic to issue
warnings; the same seems to apply to -std=c99 for at least some features that
were included in gnu* standards like anonymous structures and unions.

The latter is probably a particular indication about the desirability of this,
since the extension we are talking about is a relatively obvious extension of
the anonymous struct/union construct!

It is an incredibly useful thing in ABI headers, because it lets you avoid the
"copy/macro this entire structure definition into another."

	-hpa

On Mon, 23 Feb 2026, at 20:10, Nathan Chancellor wrote:
> Hi all,
>
> The kernel enabled '-fms-extensions' in commit c4781dc3d1cf ("Kbuild:
> enable -fms-extensions") in 6.19 to gain access to a Microsoft
> (originally Plan 9) extension around including a tagged structure/union
> anonymously in an other structure/union. Since then, Clang 23.0.0
> (current main) has added a flag to enable only that extension, rather
> than all Microsoft extensions, '-fms-anonymous-structs' [1]. Using this
> narrower compiler option would have avoided the build error fixed by
> commit a6773e6932cb ("jfs: Rename _inline to avoid conflict with clang's
> '-fms-extensions'"). While these errors are not expected to be common,
> using the narrower option when available has no drawbacks because the
> kernel only cares about this extension in '-fms-extensions', no others.
> While this could result in build errors for folks using
> '-fms-anonymous-structs' if a developer uses another extension in
> '-fms-extensions' (either intentionally or unintentionally), flagging
> these uses for further scrutiny seems worthwhile.
>
> This series converts the build system to use that flag when it is
> available. The first patch consolidates all of the C dialect flags into
> a single variable to make future updates to the dialect flags less
> painful, as updating the logic in every place that uses their custom
> built C flags is getting cumbersome (and C23 is looming). The second
> patch makes the actual switch.
>
> I would like Nicolas to carry this in the Kbuild tree for 7.1, please
> provide Acks as necessary.
>
> [1]: 
> https://github.com/llvm/llvm-project/commit/c391efe6fb67329d8e2fd231692cc6b0ea902956
>
> ---
> Nathan Chancellor (2):
>       kbuild: Consolidate C dialect options
>       kbuild: Use '-fms-anonymous-structs' if it is available
>

Acked-by: Ard Biesheuvel <ardb@kernel.org>

On 2/23/26 20:38, Ard Biesheuvel wrote:
> 
> 
> On Mon, 23 Feb 2026, at 20:10, Nathan Chancellor wrote:
>> Hi all,
>>
>> The kernel enabled '-fms-extensions' in commit c4781dc3d1cf ("Kbuild:
>> enable -fms-extensions") in 6.19 to gain access to a Microsoft
>> (originally Plan 9) extension around including a tagged structure/union
>> anonymously in an other structure/union. Since then, Clang 23.0.0
>> (current main) has added a flag to enable only that extension, rather
>> than all Microsoft extensions, '-fms-anonymous-structs' [1]. Using this
>> narrower compiler option would have avoided the build error fixed by
>> commit a6773e6932cb ("jfs: Rename _inline to avoid conflict with clang's
>> '-fms-extensions'"). While these errors are not expected to be common,
>> using the narrower option when available has no drawbacks because the
>> kernel only cares about this extension in '-fms-extensions', no others.
>> While this could result in build errors for folks using
>> '-fms-anonymous-structs' if a developer uses another extension in
>> '-fms-extensions' (either intentionally or unintentionally), flagging
>> these uses for further scrutiny seems worthwhile.
>>
>> This series converts the build system to use that flag when it is
>> available. The first patch consolidates all of the C dialect flags into
>> a single variable to make future updates to the dialect flags less
>> painful, as updating the logic in every place that uses their custom
>> built C flags is getting cumbersome (and C23 is looming). The second
>> patch makes the actual switch.
>>
>> I would like Nicolas to carry this in the Kbuild tree for 7.1, please
>> provide Acks as necessary.
>>
>> [1]:
>> https://github.com/llvm/llvm-project/commit/c391efe6fb67329d8e2fd231692cc6b0ea902956
>>
>> ---
>> Nathan Chancellor (2):
>>        kbuild: Consolidate C dialect options
>>        kbuild: Use '-fms-anonymous-structs' if it is available
>>
> 
> Acked-by: Ard Biesheuvel <ardb@kernel.org>

For the series:
Acked-by: Helge Deller <deller@gmx.de>  # parisc

Thanks!
Helge