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

[Nathan Chancellor <nathan@kernel.org>]

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