Re: [PATCH RESEND v2] tools build: Use -fzero-init-padding-bits=all

[Quentin Monnet]

2026-02-26 10:38 UTC-0800 ~ Namhyung Kim <namhyung@xxxxxxxxxx>
> Adding bpftool maintainer.
> 
> On Tue, Feb 24, 2026 at 12:16:40PM +0000, Leo Yan wrote:
>> GCC-15 release claims [1]:
>>
>>   {0} initializer in C or C++ for unions no longer guarantees clearing
>>   of the whole union (except for static storage duration initialization),
>>   it just initializes the first union member to zero. If initialization
>>   of the whole union including padding bits is desirable, use {} (valid
>>   in C23 or C++) or use -fzero-init-padding-bits=unions option to
>>   restore old GCC behavior.
>>
>> As a result, this new behaviour might cause unexpected data when we
>> initialize a union with using the '{ 0 }' initializer.
>>
>> Since commit dce4aab8441d ("kbuild: Use -fzero-init-padding-bits=all"),
>> the kernel has enabled -fzero-init-padding-bits=all to zero padding bits
>> in unions and structures.  This commit applies the same option for tools
>> building.
>>
>> The option is not supported neither by any version older than GCC 15 and
>> is also not supported by LLVM, this patch adds the cc-option function to
>> dynamically detect the compiler option.
>>
>> [1] https://gcc.gnu.org/gcc-15/changes.html
>>
>> Signed-off-by: Leo Yan <leo.yan@xxxxxxx>


Thank you Namhyung for the Cc.

I built bpftool with the patch, with gcc 13 (which didn't get the flag,
as expected) and gcc 15, and it's fine with both. As far as I can tell,
bpftool does not initialise any union with "{0}" anyway.

One potential concern (I didn't try) could be for cross-compilation:
bpftool's Makefile sets HOST_CFLAGS based on $(CFLAGS), but $(HOSTCC)
and $(CC) could be different versions of gcc, for example. The same
concern could apply to perf with HOSTCFLAGS, by the way?

Best regards,
Quentin


Note: For fellow bpf@ readers, the original thread is at
https://lore.kernel.org/linux-kbuild/aaCTC86U9KjnmZmu@xxxxxxxxxx/T/#m700907de1a84c007bfda62981af590ad7aed0f11