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
