[PATCH RFC next 00/18] sync scripts/Makefile.extrawarn with 6.1, enable WERROR for host tools

[Tom Rini]

On Tue, May 05, 2026 at 01:58:26PM +0200, Quentin Schulz wrote:
> Hi Tom,
> 
> On 5/4/26 8:04 PM, Tom Rini wrote:
> > On Mon, May 04, 2026 at 03:20:27PM +0200, Quentin Schulz wrote:
> [...]
> > > The first two patches are for fixing pytest calling make directly on a
> > > "dirty" build directory as generated by buildman using the clang-20
> > > toolchain, but pytest does not set HOSTCC and CC to clang-20, resulting
> > > in clang flags being used with gcc).
> > > 
> > > One can simply reproduce it (after backporting up to patch
> > > "scripts/Makefile.extrawarn: sync with 6.1") by doing so in the
> > > container:
> > > 
> > > make HOSTCC=clang-20 CC=clang-20 O=build/sandbox sandbox_defconfig
> > > make HOSTCC=clang-20 CC=clang-20 O=build/sandbox -j`nproc
> > > make O=build/sandbox u-boot-initial-env
> > > 
> > > It'll print:
> > > gcc: error: unrecognized command-line option '-mno-global-merge'
> > > gcc: error: unrecognized command-line option '-Wformat-invalid-specifier'
> > > gcc: error: unrecognized command-line option '-Qunused-arguments'
> > > 
> > > This is essentially what's run within test_env_initial_env_file in
> > > test/py/tests/test_env.py.
> > > 
> > > While I'm not unhappy with the patches to pytest, it feels to me we may
> > > be missing something else for the u-boot-initial-env make target to
> > > update the kconfig symbol based on the toolchain being used when called.
> > 
> > Is there some other target in the Makefile that should catch this kind
> > of change? It's not just that build target that needs to be remade, it's
> > everything, yes?
> > 
> 
> For the reproducer, one actually needs to do
> 
> diff --git a/Makefile b/Makefile
> index bd33437fdfd..9079131f81e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1007,15 +1007,15 @@ KBUILD_CFLAGS += $(call
> cc-option,-Wno-format-nonliteral)
>  KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
> 
>  ifdef CONFIG_CC_IS_CLANG
> -KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
> -KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
> -KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
> +KBUILD_CPPFLAGS += -Qunused-arguments
> +KBUILD_CFLAGS += -Wno-format-invalid-specifier
> +KBUILD_CFLAGS += -Wno-gnu
>  # Quiet clang warning: comparison of unsigned expression < 0 is always
> false
> -KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
> +KBUILD_CFLAGS += -Wno-tautological-compare
>  # CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as
> the
>  # source of a reference will be _MergedGlobals and not on of the
> whitelisted names.
>  # See modpost pattern 2
> -KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
> +KBUILD_CFLAGS += -mno-global-merge
>  else
> 
>  # These warnings generated too much noise in a regular build.
> 
> Which is what's being done since kernel commit a1494304346a ("kbuild: add
> all Clang-specific flags unconditionally"). I actually had this in an
> earlier version of this patch series and forgot I removed it.
> 
> This seems to apply to envtools and tools-only as well, though make prompts
> me for the desired state of symbols that are now reachable, e.g.
> ARM64_CRC32. And if I rerun the same command, then it works. It seems like
> the config from the previous run is used? I don't know if it's related but
> those two commands call make directly ($(Q)$(MAKE) $(build)=<path>). Do you
> have something in mind maybe? Or some more commands to run?

I think I partly misunderstood at first. It's not that we switch from
one toolchain to another, it's that we can't (as easily) use gcc for the
target and clang for host tools (and vice-versa) because of how flags
are set now, yes? If so, how does this work in the kernel?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260505/0801a395/attachment.sig>