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

[Leo Yan <leo.yan@arm.com>]

On Thu, Feb 26, 2026 at 10:52:01PM +0000, Quentin Monnet wrote:
> 2026-02-26 10:38 UTC-0800 ~ Namhyung Kim <namhyung@kernel.org>
> > 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@arm.com>
> 
> 
> 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.

Thanks a lot for testing!

> 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.

To avoid confusion, we can use EXTRA_CFLAGS and HOST_EXTRACFLAGS instead
in Makefile.include:

-----

# cc-option
# Usage: CFLAGS += $(call cc-option,-march=winchip-c6,-march=i586)
cc-option = $(call try-run, \
       $(CC) -Werror $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))

host-cc-option = $(call try-run, \
       $(HOSTCC) -Werror $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2))

# Explicitly clear padding bits with the initializer '{ 0 }'
EXTRA_CFLAGS += $(call cc-option,-fzero-init-padding-bits=all)
HOST_EXTRACFLAGS += $(call host-cc-option,-fzero-init-padding-bits=all)

-----

Then, in a project, its Makefile can append EXTRA_CFLAGS and
HOST_EXTRACFLAGS to CFLAGS and HOSTCFLAGS respectively.

If this is fine for us, I will repin patches

> The same concern could apply to perf with HOSTCFLAGS, by the way?

I don't see perf's HOSTCFLAGS to reuse CFLAGS.

Thanks,
Leo