Re: Build failure with GCC 15 (-std=gnu23)

Re: Build failure with GCC 15 (-std=gnu23)

[Nathan Chancellor]

Hi Kostadin,

Just a quick FYI off the bat, you only directed this to LKML, which is
basically like sending it into the void because very few people actually
read every message on LKML. I only caught it because I have a filter set
up for mentions of Clang and LLVM. I'd suggest adding at least the
Kbuild mailing list, which I have done now. I have also added Arnd
because I seem to recall him looking into how hard it would be to build
the kernel with C23.

On Mon, Nov 18, 2024 at 02:26:49PM +0000, Kostadin Shishmanov wrote:
> Whenever I try to build the kernel with upcoming GCC 15 which defaults to -std=gnu23 I get a build failure:
> 
> ```
> In file included from ./include/uapi/linux/posix_types.h:5,
>                  from ./include/uapi/linux/types.h:14,
>                  from ./include/linux/types.h:6,
>                  from ./include/uapi/linux/mei_uuid.h:12,
>                  from ./include/uapi/linux/mei.h:10,
>                  from ./include/linux/mod_devicetable.h:12,
>                  from scripts/mod/devicetable-offsets.c:3:
> ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
>    11 |         false   = 0,
> ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
>    35 | typedef _Bool                   bool;
> ./include/linux/types.h:35:1: warning: useless type name in empty declaration
>    35 | typedef _Bool                   bool;
> ```
> 
> This can be reproduced on older GCC versions with KCFLAGS="-std=gnu23"

The kernel builds explicitly with '-std=gnu11' (see Makefile), so I
would not expect the default switch on the GCC side to matter. That
signals to me that we are not actually using that flag everywhere then?
Building with V=1, I can see '-std=gnu11' in the compiler command for
scripts/mod/devicetable-offsets.s, which is generated from
scripts/mod/devicetable-offsets.c, so it seems like something else is
going on here?

> With Clang 18 and KCFLAGS="-std=c23" it's an even bigger mess:

I think the error below occurs because you used 'c23' instead of
'gnu23'. GCC's documentation states:

"The asm keyword is a GNU extension. When writing code that can be
compiled with -ansi and the various -std options, use __asm__ instead of
asm (see Alternate Keywords)."

https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

Cheers,
Nathan

> ```
> In file included from ./arch/x86/include/asm/jump_label.h:7,
>                  from ./include/linux/jump_label.h:112,
>                  from ./arch/x86/include/asm/string_64.h:6,
>                  from ./arch/x86/include/asm/string.h:5,
>                  from ./include/linux/string.h:64,
>                  from ./include/linux/uuid.h:11,
>                  from ./include/linux/mod_devicetable.h:14:
> ./arch/x86/include/asm/asm.h: In function ‘rip_rel_ptr’:
> ./arch/x86/include/asm/asm.h:120:9: error: implicit declaration of function ‘asm’ [-Wimplicit-function-declaration]
>   120 |         asm("leaq %c1(%%rip), %0" : "=r"(p) : "i"(p));
> ./arch/x86/include/asm/asm.h:120:34: error: expected ‘)’ before ‘:’ token
>   120 |         asm("leaq %c1(%%rip), %0" : "=r"(p) : "i"(p));
> ./arch/x86/include/asm/asm.h: At top level:
> ./arch/x86/include/asm/asm.h:222:46: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘asm’
>   222 | register unsigned long current_stack_pointer asm(_ASM_SP);
> ./arch/x86/include/asm/jump_label.h: In function ‘arch_static_branch’:
> ./arch/x86/include/asm/jump_label.h:27:9: error: ‘asm’ undeclared (first use in this function)
>    27 |         asm goto("1:"
> ./arch/x86/include/asm/jump_label.h:27:9: note: each undeclared identifier is reported only once for each function it appears in
> ./arch/x86/include/asm/jump_label.h:27:12: error: expected ‘;’ before ‘goto’
>    27 |         asm goto("1:"
>                   ;
> In file included from ./include/uapi/linux/swab.h:8,
>                  from ./include/linux/swab.h:5,
>                  from ./include/uapi/linux/byteorder/little_endian.h:14,
>                  from ./include/linux/byteorder/little_endian.h:5,
>                  from ./arch/x86/include/uapi/asm/byteorder.h:5,
>                  from ./include/linux/bitfield.h:11,
>                  from ./include/linux/fortify-string.h:5,
>                  from ./include/linux/string.h:390:
> ./arch/x86/include/uapi/asm/swab.h: In function ‘__arch_swab32’:
> ./arch/x86/include/uapi/asm/swab.h:10:24: error: expected ‘)’ before ‘:’ token
>    10 |         asm("bswapl %0" : "=r" (val) : "0" (val));
>                                )
> ./arch/x86/include/uapi/asm/swab.h: In function ‘__arch_swab64’:
> ./arch/x86/include/uapi/asm/swab.h:31:24: error: expected ‘)’ before ‘:’ token
>    31 |         asm("bswapq %0" : "=r" (val) : "0" (val));
>                                )
> In file included from scripts/mod/devicetable-offsets.c:2:
> scripts/mod/devicetable-offsets.c: In function ‘main’:
> ./include/linux/kbuild.h:6:9: error: ‘asm’ undeclared (first use in this function)
>     6 |         asm volatile("\n.ascii \"->" #sym " %0 " #val "\"" : : "i" (val))
> scripts/mod/devicetable-offsets.c:5:22: note: in expansion of macro ‘DEFINE’
>     5 | #define DEVID(devid) DEFINE(SIZE_##devid, sizeof(struct devid))
> scripts/mod/devicetable-offsets.c:11:9: note: in expansion of macro ‘DEVID’
>    11 |         DEVID(usb_device_id);
> ./include/linux/kbuild.h:6:13: error: expected ‘;’ before ‘volatile’
>     6 |         asm volatile("\n.ascii \"->" #sym " %0 " #val "\"" : : "i" (val))
> ```
> 
> There is a lot more output from the compiler that i've cut off because the email would become way too long.
> 
> Regards,
> Kostadin
> 

Re: Build failure with GCC 15 (-std=gnu23)

[Sam James]

Nathan Chancellor <nathan@kernel.org> writes:

> Hi Kostadin,
>
> Just a quick FYI off the bat, you only directed this to LKML, which is
> basically like sending it into the void because very few people actually
> read every message on LKML. I only caught it because I have a filter set
> up for mentions of Clang and LLVM. I'd suggest adding at least the
> Kbuild mailing list, which I have done now. I have also added Arnd
> because I seem to recall him looking into how hard it would be to build
> the kernel with C23.

FWIW, scripts/get_maintainers.pl for stddef.h and types.h doesn't
include kbuild -- maybe we should add that in.

>
> On Mon, Nov 18, 2024 at 02:26:49PM +0000, Kostadin Shishmanov wrote:
>> Whenever I try to build the kernel with upcoming GCC 15 which defaults to -std=gnu23 I get a build failure:
>> 
>> ```
>> In file included from ./include/uapi/linux/posix_types.h:5,
>>                  from ./include/uapi/linux/types.h:14,
>>                  from ./include/linux/types.h:6,
>>                  from ./include/uapi/linux/mei_uuid.h:12,
>>                  from ./include/uapi/linux/mei.h:10,
>>                  from ./include/linux/mod_devicetable.h:12,
>>                  from scripts/mod/devicetable-offsets.c:3:
>> ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
>>    11 |         false   = 0,
>> ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers
>>    35 | typedef _Bool                   bool;
>> ./include/linux/types.h:35:1: warning: useless type name in empty declaration
>>    35 | typedef _Bool                   bool;
>> ```
>> 
>> This can be reproduced on older GCC versions with KCFLAGS="-std=gnu23"
>
> The kernel builds explicitly with '-std=gnu11' (see Makefile), so I
> would not expect the default switch on the GCC side to matter. That
> signals to me that we are not actually using that flag everywhere
> then?

Right, that's the conclusion I reached when discussing it with Kostadin.

> Building with V=1, I can see '-std=gnu11' in the compiler command for
> scripts/mod/devicetable-offsets.s, which is generated from
> scripts/mod/devicetable-offsets.c, so it seems like something else is
> going on here?

I can reproduce it with `make defconfig` at
158f238aa69d91ad74e535c73f552bd4b025109c in Linus' tree with just `make
V=1 -j$(nproc) -l$(nproc)` (i.e. no CFLAGS manipulation at all).

```
# CC      drivers/firmware/efi/libstub/x86-5lvl.o
  gcc -Wp,-MMD,drivers/firmware/efi/libstub/.x86-5lvl.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/genera
ted/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__
 -fmacro-prefix-map=./= -mcmodel=small -m64 -D__KERNEL__ -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -Wno-pointer-sign -Wno-address-of-packed-member -fno-asy
nchronous-unwind-tables -Os -DDISABLE_BRANCH_PROFILING -include ./include/linux/hidden.h -D__NO_FORTIFY -ffreestanding -fno-stack-protector -D__DISABLE_EXPORTS    -DKBUILD_MODFILE='"driv
ers/firmware/efi/libstub/x86-5lvl"' -DKBUILD_BASENAME='"x86_5lvl"' -DKBUILD_MODNAME='"x86_5lvl"' -D__KBUILD_MODNAME=kmod_x86_5lvl -c -o drivers/firmware/efi/libstub/x86-5lvl.o drivers/fi
rmware/efi/libstub/x86-5lvl.c
In file included from ./include/uapi/linux/posix_types.h:5,
                 from ./include/uapi/linux/types.h:14,
                 from ./include/linux/types.h:6,
                 from ./include/linux/kasan-checks.h:5,
                 from ./include/asm-generic/rwonce.h:26,
                 from ./arch/x86/include/generated/asm/rwonce.h:1,
                 from ./include/linux/compiler.h:317,
                 from ./include/linux/build_bug.h:5,
                 from ./include/linux/init.h:5,
                 from ./include/linux/efi.h:15,
                 from drivers/firmware/efi/libstub/file.c:10:
./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
   11 |         false   = 0,
      |         ^~~~~
```

-std=gnu11 certainly isn't there.

>
> [...]

thanks,
sam

Re: Build failure with GCC 15 (-std=gnu23)

[Nathan Chancellor]

On Tue, Nov 19, 2024 at 02:57:28AM +0000, Sam James wrote:
> Nathan Chancellor <nathan@kernel.org> writes:
> 
> > Hi Kostadin,
> >
> > Just a quick FYI off the bat, you only directed this to LKML, which is
> > basically like sending it into the void because very few people actually
> > read every message on LKML. I only caught it because I have a filter set
> > up for mentions of Clang and LLVM. I'd suggest adding at least the
> > Kbuild mailing list, which I have done now. I have also added Arnd
> > because I seem to recall him looking into how hard it would be to build
> > the kernel with C23.
> 
> FWIW, scripts/get_maintainers.pl for stddef.h and types.h doesn't
> include kbuild -- maybe we should add that in.

Yeah, it would be good to have someone own these files. Not sure it
makes sense for Kbuild to be it though, I merely suggested that since
the actual root cause of the error is more in Kbuild's realm.

> I can reproduce it with `make defconfig` at
> 158f238aa69d91ad74e535c73f552bd4b025109c in Linus' tree with just `make
> V=1 -j$(nproc) -l$(nproc)` (i.e. no CFLAGS manipulation at all).
> 
> ```
> # CC      drivers/firmware/efi/libstub/x86-5lvl.o
>   gcc -Wp,-MMD,drivers/firmware/efi/libstub/.x86-5lvl.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/genera
> ted/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__
>  -fmacro-prefix-map=./= -mcmodel=small -m64 -D__KERNEL__ -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -Wno-pointer-sign -Wno-address-of-packed-member -fno-asy
> nchronous-unwind-tables -Os -DDISABLE_BRANCH_PROFILING -include ./include/linux/hidden.h -D__NO_FORTIFY -ffreestanding -fno-stack-protector -D__DISABLE_EXPORTS    -DKBUILD_MODFILE='"driv
> ers/firmware/efi/libstub/x86-5lvl"' -DKBUILD_BASENAME='"x86_5lvl"' -DKBUILD_MODNAME='"x86_5lvl"' -D__KBUILD_MODNAME=kmod_x86_5lvl -c -o drivers/firmware/efi/libstub/x86-5lvl.o drivers/fi
> rmware/efi/libstub/x86-5lvl.c
> In file included from ./include/uapi/linux/posix_types.h:5,
>                  from ./include/uapi/linux/types.h:14,
>                  from ./include/linux/types.h:6,
>                  from ./include/linux/kasan-checks.h:5,
>                  from ./include/asm-generic/rwonce.h:26,
>                  from ./arch/x86/include/generated/asm/rwonce.h:1,
>                  from ./include/linux/compiler.h:317,
>                  from ./include/linux/build_bug.h:5,
>                  from ./include/linux/init.h:5,
>                  from ./include/linux/efi.h:15,
>                  from drivers/firmware/efi/libstub/file.c:10:
> ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
>    11 |         false   = 0,
>       |         ^~~~~
> ```
> 
> -std=gnu11 certainly isn't there.

Ugh, this is because drivers/firmware/efi/libstub does not use
KBUILD_CFLAGS from the rest of the kernel when targeting x86:

$ sed -n '9,21p' drivers/firmware/efi/libstub/Makefile
# non-x86 reuses KBUILD_CFLAGS, x86 does not
cflags-y                        := $(KBUILD_CFLAGS)

cflags-$(CONFIG_X86_32)         := -march=i386
cflags-$(CONFIG_X86_64)         := -mcmodel=small
cflags-$(CONFIG_X86)            += -m$(BITS) -D__KERNEL__ \
                                   -fPIC -fno-strict-aliasing -mno-red-zone \
                                   -mno-mmx -mno-sse -fshort-wchar \
                                   -Wno-pointer-sign \
                                   $(call cc-disable-warning, address-of-packed-member) \
                                   $(call cc-disable-warning, gnu) \
                                   -fno-asynchronous-unwind-tables \
                                   $(CLANG_FLAGS)

This isn't the first time this peculiarity has bitten us :/ sticking
'-std=gnu11' in there should resolve that issue.

arch/x86/boot/compressed/Makefile might need the same treatment. It
might make sense to introduce something like 'CSTD_FLAG := -std=gnu11'
then use that in the various places within the kernel that need it so it
can be consistently updated in the future whenever needed. I see that
flag in Makefile, arch/arm64/kernel/vdso32/Makefile, and
arch/x86/Makefile.

Cheers,
Nathan

Re: Build failure with GCC 15 (-std=gnu23)

[Sam James]

Nathan Chancellor <nathan@kernel.org> writes:

> On Tue, Nov 19, 2024 at 02:57:28AM +0000, Sam James wrote:
>> Nathan Chancellor <nathan@kernel.org> writes:
>> 
>> > Hi Kostadin,
>> >
>> > Just a quick FYI off the bat, you only directed this to LKML, which is
>> > basically like sending it into the void because very few people actually
>> > read every message on LKML. I only caught it because I have a filter set
>> > up for mentions of Clang and LLVM. I'd suggest adding at least the
>> > Kbuild mailing list, which I have done now. I have also added Arnd
>> > because I seem to recall him looking into how hard it would be to build
>> > the kernel with C23.
>> 
>> FWIW, scripts/get_maintainers.pl for stddef.h and types.h doesn't
>> include kbuild -- maybe we should add that in.
>
> Yeah, it would be good to have someone own these files. Not sure it
> makes sense for Kbuild to be it though, I merely suggested that since
> the actual root cause of the error is more in Kbuild's realm.

Yeah, I couldn't figure out who a better person would be either :|

>
>> I can reproduce it with `make defconfig` at
>> 158f238aa69d91ad74e535c73f552bd4b025109c in Linus' tree with just `make
>> V=1 -j$(nproc) -l$(nproc)` (i.e. no CFLAGS manipulation at all).
>> 
>> ```
>> # CC      drivers/firmware/efi/libstub/x86-5lvl.o
>>   gcc -Wp,-MMD,drivers/firmware/efi/libstub/.x86-5lvl.o.d -nostdinc -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/genera
>> ted/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__
>>  -fmacro-prefix-map=./= -mcmodel=small -m64 -D__KERNEL__ -fPIC -fno-strict-aliasing -mno-red-zone -mno-mmx -mno-sse -fshort-wchar -Wno-pointer-sign -Wno-address-of-packed-member -fno-asy
>> nchronous-unwind-tables -Os -DDISABLE_BRANCH_PROFILING -include ./include/linux/hidden.h -D__NO_FORTIFY -ffreestanding -fno-stack-protector -D__DISABLE_EXPORTS    -DKBUILD_MODFILE='"driv
>> ers/firmware/efi/libstub/x86-5lvl"' -DKBUILD_BASENAME='"x86_5lvl"' -DKBUILD_MODNAME='"x86_5lvl"' -D__KBUILD_MODNAME=kmod_x86_5lvl -c -o drivers/firmware/efi/libstub/x86-5lvl.o drivers/fi
>> rmware/efi/libstub/x86-5lvl.c
>> In file included from ./include/uapi/linux/posix_types.h:5,
>>                  from ./include/uapi/linux/types.h:14,
>>                  from ./include/linux/types.h:6,
>>                  from ./include/linux/kasan-checks.h:5,
>>                  from ./include/asm-generic/rwonce.h:26,
>>                  from ./arch/x86/include/generated/asm/rwonce.h:1,
>>                  from ./include/linux/compiler.h:317,
>>                  from ./include/linux/build_bug.h:5,
>>                  from ./include/linux/init.h:5,
>>                  from ./include/linux/efi.h:15,
>>                  from drivers/firmware/efi/libstub/file.c:10:
>> ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’
>>    11 |         false   = 0,
>>       |         ^~~~~
>> ```
>> 
>> -std=gnu11 certainly isn't there.
>
> Ugh, this is because drivers/firmware/efi/libstub does not use
> KBUILD_CFLAGS from the rest of the kernel when targeting x86:
>
> $ sed -n '9,21p' drivers/firmware/efi/libstub/Makefile
> # non-x86 reuses KBUILD_CFLAGS, x86 does not
> cflags-y                        := $(KBUILD_CFLAGS)
>
> cflags-$(CONFIG_X86_32)         := -march=i386
> cflags-$(CONFIG_X86_64)         := -mcmodel=small
> cflags-$(CONFIG_X86)            += -m$(BITS) -D__KERNEL__ \
>                                    -fPIC -fno-strict-aliasing -mno-red-zone \
>                                    -mno-mmx -mno-sse -fshort-wchar \
>                                    -Wno-pointer-sign \
>                                    $(call cc-disable-warning, address-of-packed-member) \
>                                    $(call cc-disable-warning, gnu) \
>                                    -fno-asynchronous-unwind-tables \
>                                    $(CLANG_FLAGS)
>
> This isn't the first time this peculiarity has bitten us :/ sticking
> '-std=gnu11' in there should resolve that issue.
>
> arch/x86/boot/compressed/Makefile might need the same treatment. It
> might make sense to introduce something like 'CSTD_FLAG := -std=gnu11'
> then use that in the various places within the kernel that need it so it
> can be consistently updated in the future whenever needed. I see that
> flag in Makefile, arch/arm64/kernel/vdso32/Makefile, and
> arch/x86/Makefile.

This is the conclusion I just reached, although I'm struggling to figure
out a nice place to put it without sprinkling it all over the place. I'm
inclined to wait until kbuild folks weigh in so I don't do a lot of
(trivial, but tedious) work that needs changing.

As a hack, I've injected it into CLANG_FLAGS locally for now as it
happens to appear in all the right places ;)

>
> Cheers,
> Nathan

thanks,
sam

Re: Build failure with GCC 15 (-std=gnu23)

[Nathan Chancellor]

On Tue, Nov 19, 2024 at 04:24:41AM +0000, Sam James wrote:
> This is the conclusion I just reached, although I'm struggling to figure
> out a nice place to put it without sprinkling it all over the place. I'm
> inclined to wait until kbuild folks weigh in so I don't do a lot of
> (trivial, but tedious) work that needs changing.

Sure. Masahiro, do you have any thoughts here? You can see the beginning
of the thread at [1].

I think the diff below would be a good first patch in a series that adds
it to every other place that needs it. As you noticed, it probably makes
sense to add it to most places that have CLANG_FLAGS, as that is a good
indicator that KBUILD_CFLAGS is not being used properly in those spots.

> As a hack, I've injected it into CLANG_FLAGS locally for now as it
> happens to appear in all the right places ;)

:) exactly why I am quite familiar with this issue...

[1]: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvduultkgfAIRZI3vQpZylu7Gl929HaYFRGeMEalWCpeMzCIIhLxxRhq4U-Y=@protonmail.com/

Cheers,
Nathan

diff --git a/Makefile b/Makefile
index 68a8faff2543..33cc6bcf39b5 100644
--- a/Makefile
+++ b/Makefile
@@ -416,6 +416,8 @@ export KCONFIG_CONFIG
 # SHELL used by kbuild
 CONFIG_SHELL := sh
 
+CSTD_FLAG := -std=gnu11
+
 HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS 2>/dev/null)
 HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS 2>/dev/null)
 HOST_LFS_LIBS := $(shell getconf LFS_LIBS 2>/dev/null)
@@ -437,7 +439,7 @@ HOSTRUSTC = rustc
 HOSTPKG_CONFIG	= pkg-config
 
 KBUILD_USERHOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
-			 -O2 -fomit-frame-pointer -std=gnu11
+			 -O2 -fomit-frame-pointer $(CSTD_FLAG)
 KBUILD_USERCFLAGS  := $(KBUILD_USERHOSTCFLAGS) $(USERCFLAGS)
 KBUILD_USERLDFLAGS := $(USERLDFLAGS)
 
@@ -545,7 +547,7 @@ LINUXINCLUDE    := \
 KBUILD_AFLAGS   := -D__ASSEMBLY__ -fno-PIE
 
 KBUILD_CFLAGS :=
-KBUILD_CFLAGS += -std=gnu11
+KBUILD_CFLAGS += $(CSTD_FLAG)
 KBUILD_CFLAGS += -fshort-wchar
 KBUILD_CFLAGS += -funsigned-char
 KBUILD_CFLAGS += -fno-common
@@ -589,7 +591,7 @@ export CPP AR NM STRIP OBJCOPY OBJDUMP READELF PAHOLE RESOLVE_BTFIDS LEX YACC AW
 export PERL PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
 export KGZIP KBZIP2 KLZOP LZMA LZ4 XZ ZSTD
 export KBUILD_HOSTCXXFLAGS KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS LDFLAGS_MODULE
-export KBUILD_USERCFLAGS KBUILD_USERLDFLAGS
+export KBUILD_USERCFLAGS KBUILD_USERLDFLAGS CSTD_FLAG
 
 export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS KBUILD_LDFLAGS
 export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
index 25a2cb6317f3..5f9d5c38ed9e 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -65,7 +65,7 @@ VDSO_CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                -fno-strict-aliasing -fno-common \
                -Werror-implicit-function-declaration \
                -Wno-format-security \
-               -std=gnu11
+               $(CSTD_FLAG)
 VDSO_CFLAGS  += -O2
 # Some useful compiler-dependent flags from top-level Makefile
 VDSO_CFLAGS += $(call cc32-option,-Wno-pointer-sign)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5b773b34768d..d5c851dd0653 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -47,7 +47,7 @@ endif
 
 # How to compile the 16-bit code.  Note we always compile for -march=i386;
 # that way we can complain to the user if the CPU is insufficient.
-REALMODE_CFLAGS	:= -std=gnu11 -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS \
+REALMODE_CFLAGS	:= $(CSTD_FLAG) -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS \
 		   -Wall -Wstrict-prototypes -march=i386 -mregparm=3 \
 		   -fno-strict-aliasing -fomit-frame-pointer -fno-pic \
 		   -mno-mmx -mno-sse $(call cc-option,-fcf-protection=none)

Re: Build failure with GCC 15 (-std=gnu23)

[Masahiro Yamada]

On Tue, Nov 19, 2024 at 1:47 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Tue, Nov 19, 2024 at 04:24:41AM +0000, Sam James wrote:
> > This is the conclusion I just reached, although I'm struggling to figure
> > out a nice place to put it without sprinkling it all over the place. I'm
> > inclined to wait until kbuild folks weigh in so I don't do a lot of
> > (trivial, but tedious) work that needs changing.
>
> Sure. Masahiro, do you have any thoughts here? You can see the beginning
> of the thread at [1].
>
> I think the diff below would be a good first patch in a series that adds
> it to every other place that needs it. As you noticed, it probably makes
> sense to add it to most places that have CLANG_FLAGS, as that is a good
> indicator that KBUILD_CFLAGS is not being used properly in those spots.

I do not think this would solve the issue.

The attached diff will be useful when we bump -std=gnu* next time;
we would only need to change the single line.
However, this kind of change does not occur quite often.
Anyway, we would do "git grep std=gnu11" to make sure there is no left-over.

It is not helpful to detect the reported issue in
drivers/firmware/efi/libstub/Makefile.

Some Makefile overriding KBUILD_CFLAGS would forget to add
$(CSTD_FLAG), for the same reason as they would forget to add
-std=gnu11.









> > As a hack, I've injected it into CLANG_FLAGS locally for now as it
> > happens to appear in all the right places ;)
>
> :) exactly why I am quite familiar with this issue...
>
> [1]: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvduultkgfAIRZI3vQpZylu7Gl929HaYFRGeMEalWCpeMzCIIhLxxRhq4U-Y=@protonmail.com/
>
> Cheers,
> Nathan
>
> diff --git a/Makefile b/Makefile
> index 68a8faff2543..33cc6bcf39b5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -416,6 +416,8 @@ export KCONFIG_CONFIG
>  # SHELL used by kbuild
>  CONFIG_SHELL := sh
>
> +CSTD_FLAG := -std=gnu11
> +
>  HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS 2>/dev/null)
>  HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS 2>/dev/null)
>  HOST_LFS_LIBS := $(shell getconf LFS_LIBS 2>/dev/null)
> @@ -437,7 +439,7 @@ HOSTRUSTC = rustc
>  HOSTPKG_CONFIG = pkg-config
>
>  KBUILD_USERHOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
> -                        -O2 -fomit-frame-pointer -std=gnu11
> +                        -O2 -fomit-frame-pointer $(CSTD_FLAG)
>  KBUILD_USERCFLAGS  := $(KBUILD_USERHOSTCFLAGS) $(USERCFLAGS)
>  KBUILD_USERLDFLAGS := $(USERLDFLAGS)
>
> @@ -545,7 +547,7 @@ LINUXINCLUDE    := \
>  KBUILD_AFLAGS   := -D__ASSEMBLY__ -fno-PIE
>
>  KBUILD_CFLAGS :=
> -KBUILD_CFLAGS += -std=gnu11
> +KBUILD_CFLAGS += $(CSTD_FLAG)
>  KBUILD_CFLAGS += -fshort-wchar
>  KBUILD_CFLAGS += -funsigned-char
>  KBUILD_CFLAGS += -fno-common
> @@ -589,7 +591,7 @@ export CPP AR NM STRIP OBJCOPY OBJDUMP READELF PAHOLE RESOLVE_BTFIDS LEX YACC AW
>  export PERL PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
>  export KGZIP KBZIP2 KLZOP LZMA LZ4 XZ ZSTD
>  export KBUILD_HOSTCXXFLAGS KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS LDFLAGS_MODULE
> -export KBUILD_USERCFLAGS KBUILD_USERLDFLAGS
> +export KBUILD_USERCFLAGS KBUILD_USERLDFLAGS CSTD_FLAG
>
>  export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS KBUILD_LDFLAGS
>  export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> index 25a2cb6317f3..5f9d5c38ed9e 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -65,7 +65,7 @@ VDSO_CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>                 -fno-strict-aliasing -fno-common \
>                 -Werror-implicit-function-declaration \
>                 -Wno-format-security \
> -               -std=gnu11
> +               $(CSTD_FLAG)
>  VDSO_CFLAGS  += -O2
>  # Some useful compiler-dependent flags from top-level Makefile
>  VDSO_CFLAGS += $(call cc32-option,-Wno-pointer-sign)
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 5b773b34768d..d5c851dd0653 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -47,7 +47,7 @@ endif
>
>  # How to compile the 16-bit code.  Note we always compile for -march=i386;
>  # that way we can complain to the user if the CPU is insufficient.
> -REALMODE_CFLAGS        := -std=gnu11 -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS \
> +REALMODE_CFLAGS        := $(CSTD_FLAG) -m16 -g -Os -DDISABLE_BRANCH_PROFILING -D__DISABLE_EXPORTS \
>                    -Wall -Wstrict-prototypes -march=i386 -mregparm=3 \
>                    -fno-strict-aliasing -fomit-frame-pointer -fno-pic \
>                    -mno-mmx -mno-sse $(call cc-option,-fcf-protection=none)



--
Best Regards
Masahiro Yamada

Re: Build failure with GCC 15 (-std=gnu23)

[Kees Cook]

On Wed, Nov 20, 2024 at 03:28:35AM +0900, Masahiro Yamada wrote:
> Some Makefile overriding KBUILD_CFLAGS would forget to add
> $(CSTD_FLAG), for the same reason as they would forget to add
> -std=gnu11.

But at least we'd have 1 place to change when we changed the std level.

FWIW, I just ran into this build failure too testing GCC 15 from their
ToT. Both EFI and compressed Makefiles needed it in my build.

-- 
Kees Cook

Re: Build failure with GCC 15 (-std=gnu23)

[Nathan Chancellor]

On Mon, Jan 20, 2025 at 04:16:30PM -0800, Kees Cook wrote:
> On Wed, Nov 20, 2024 at 03:28:35AM +0900, Masahiro Yamada wrote:
> > Some Makefile overriding KBUILD_CFLAGS would forget to add
> > $(CSTD_FLAG), for the same reason as they would forget to add
> > -std=gnu11.
> 
> But at least we'd have 1 place to change when we changed the std level.
> 
> FWIW, I just ran into this build failure too testing GCC 15 from their
> ToT. Both EFI and compressed Makefiles needed it in my build.

Yeah, I suggested the simpler diff in a separate thread, which seems to
agree with your testing:

https://lore.kernel.org/20250120182048.GA3244701@ax162/

I don't mind drafting up a commit message and sending those along if
that would be preferrable.

Cheers,
Nathan

Re: Build failure with GCC 15 (-std=gnu23)

[Sam James]

Nathan Chancellor <nathan@kernel.org> writes:

> On Mon, Jan 20, 2025 at 04:16:30PM -0800, Kees Cook wrote:
>> On Wed, Nov 20, 2024 at 03:28:35AM +0900, Masahiro Yamada wrote:
>> > Some Makefile overriding KBUILD_CFLAGS would forget to add
>> > $(CSTD_FLAG), for the same reason as they would forget to add
>> > -std=gnu11.
>> 
>> But at least we'd have 1 place to change when we changed the std level.
>> 
>> FWIW, I just ran into this build failure too testing GCC 15 from their
>> ToT. Both EFI and compressed Makefiles needed it in my build.
>
> Yeah, I suggested the simpler diff in a separate thread, which seems to
> agree with your testing:
>
> https://lore.kernel.org/20250120182048.GA3244701@ax162/
>
> I don't mind drafting up a commit message and sending those along if
> that would be preferrable.

At this point, I'd like to see the scattered -std= in given it seems
less objectionable, even if I'd prefer one place, as we already missed
one release being GCC 15-buildable. Happy to test/ack it if you're willing to send it.

thanks,
sam

Re: Build failure with GCC 15 (-std=gnu23)

[Nathan Chancellor]

On Tue, Jan 21, 2025 at 10:11:56PM +0000, Sam James wrote:
> Nathan Chancellor <nathan@kernel.org> writes:
> 
> > On Mon, Jan 20, 2025 at 04:16:30PM -0800, Kees Cook wrote:
> >> On Wed, Nov 20, 2024 at 03:28:35AM +0900, Masahiro Yamada wrote:
> >> > Some Makefile overriding KBUILD_CFLAGS would forget to add
> >> > $(CSTD_FLAG), for the same reason as they would forget to add
> >> > -std=gnu11.
> >> 
> >> But at least we'd have 1 place to change when we changed the std level.
> >> 
> >> FWIW, I just ran into this build failure too testing GCC 15 from their
> >> ToT. Both EFI and compressed Makefiles needed it in my build.
> >
> > Yeah, I suggested the simpler diff in a separate thread, which seems to
> > agree with your testing:
> >
> > https://lore.kernel.org/20250120182048.GA3244701@ax162/
> >
> > I don't mind drafting up a commit message and sending those along if
> > that would be preferrable.
> 
> At this point, I'd like to see the scattered -std= in given it seems
> less objectionable, even if I'd prefer one place, as we already missed
> one release being GCC 15-buildable. Happy to test/ack it if you're willing to send it.

Sounds good, I will get that drafted up and sent along today (if not
tomorrow) with all relevant parties on CC for testing. We can consider
unifying these flags next time we bump the version.

CHeers,
Nathan

Re: Build failure with GCC 15 (-std=gnu23)

[Arnd Bergmann]

On Tue, Nov 19, 2024, at 05:15, Nathan Chancellor wrote:
> On Tue, Nov 19, 2024 at 02:57:28AM +0000, Sam James wrote:
>> 
>> -std=gnu11 certainly isn't there.
>
> Ugh, this is because drivers/firmware/efi/libstub does not use
> KBUILD_CFLAGS from the rest of the kernel when targeting x86:
>
> $ sed -n '9,21p' drivers/firmware/efi/libstub/Makefile
> # non-x86 reuses KBUILD_CFLAGS, x86 does not
> cflags-y                        := $(KBUILD_CFLAGS)
>
> cflags-$(CONFIG_X86_32)         := -march=i386
> cflags-$(CONFIG_X86_64)         := -mcmodel=small
> cflags-$(CONFIG_X86)            += -m$(BITS) -D__KERNEL__ \
>                                    -fPIC -fno-strict-aliasing 
> -mno-red-zone \
>                                    -mno-mmx -mno-sse -fshort-wchar \
>                                    -Wno-pointer-sign \
>                                    $(call cc-disable-warning, 
> address-of-packed-member) \
>                                    $(call cc-disable-warning, gnu) \
>                                    -fno-asynchronous-unwind-tables \
>                                    $(CLANG_FLAGS)
>
> This isn't the first time this peculiarity has bitten us :/ sticking
> '-std=gnu11' in there should resolve that issue.

Could we revisit the decision to make x86 special here and
change it to use a modified KBUILD_CFLAGS like the other ones?

> arch/x86/boot/compressed/Makefile might need the same treatment. It
> might make sense to introduce something like 'CSTD_FLAG := -std=gnu11'
> then use that in the various places within the kernel that need it so it
> can be consistently updated in the future whenever needed. I see that
> flag in Makefile, arch/arm64/kernel/vdso32/Makefile, and
> arch/x86/Makefile.

I actually have a patch to make the entire kernel use -std=gnu2x,
but I never sent that because that requires gcc-9 or higher, and
has no real upsides: the main difference is the handling of 'bool'
types, and the std=gnu1x variant is simpler here because it avoids
using the compiler-provided "stdbool.h".

       Arnd

Re: Build failure with GCC 15 (-std=gnu23)

[Nathan Chancellor]

On Tue, Nov 19, 2024 at 07:53:37AM +0100, Arnd Bergmann wrote:
> On Tue, Nov 19, 2024, at 05:15, Nathan Chancellor wrote:
> > On Tue, Nov 19, 2024 at 02:57:28AM +0000, Sam James wrote:
> >> 
> >> -std=gnu11 certainly isn't there.
> >
> > Ugh, this is because drivers/firmware/efi/libstub does not use
> > KBUILD_CFLAGS from the rest of the kernel when targeting x86:
> >
> > $ sed -n '9,21p' drivers/firmware/efi/libstub/Makefile
> > # non-x86 reuses KBUILD_CFLAGS, x86 does not
> > cflags-y                        := $(KBUILD_CFLAGS)
> >
> > cflags-$(CONFIG_X86_32)         := -march=i386
> > cflags-$(CONFIG_X86_64)         := -mcmodel=small
> > cflags-$(CONFIG_X86)            += -m$(BITS) -D__KERNEL__ \
> >                                    -fPIC -fno-strict-aliasing 
> > -mno-red-zone \
> >                                    -mno-mmx -mno-sse -fshort-wchar \
> >                                    -Wno-pointer-sign \
> >                                    $(call cc-disable-warning, 
> > address-of-packed-member) \
> >                                    $(call cc-disable-warning, gnu) \
> >                                    -fno-asynchronous-unwind-tables \
> >                                    $(CLANG_FLAGS)
> >
> > This isn't the first time this peculiarity has bitten us :/ sticking
> > '-std=gnu11' in there should resolve that issue.
> 
> Could we revisit the decision to make x86 special here and
> change it to use a modified KBUILD_CFLAGS like the other ones?

I am sure that we could have a discussion with Ard and the x86 folks
about it to see what flags need to be filtered and such but we will
still need something like I suggested in other areas of the kernel,
since this is not the only place where KBUILD_CFLAGS gets blown away.

> > arch/x86/boot/compressed/Makefile might need the same treatment. It
> > might make sense to introduce something like 'CSTD_FLAG := -std=gnu11'
> > then use that in the various places within the kernel that need it so it
> > can be consistently updated in the future whenever needed. I see that
> > flag in Makefile, arch/arm64/kernel/vdso32/Makefile, and
> > arch/x86/Makefile.
> 
> I actually have a patch to make the entire kernel use -std=gnu2x,
> but I never sent that because that requires gcc-9 or higher, and
> has no real upsides: the main difference is the handling of 'bool'
> types, and the std=gnu1x variant is simpler here because it avoids
> using the compiler-provided "stdbool.h".

Ah, that's what I thought the conclusion was but I could not remember
exactly.

Cheers,
Nathan