Re: [PATCH v2 04/18] tools scripts: Short-circuit CC_NO_CLANG compiler probe in Makefile.include

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Exporting `CC_NO_CLANG` across sub-makes breaks cross-compilation when target and host compilers differ (e.g., CC=gcc and HOSTCC=clang).
- [Medium] The empty check `ifeq ($(CC_NO_CLANG),)` blindly trusts the user's external shell environment, introducing build fragility.
--

commit fd712ba4b295d8ef072e15714d284857b59a5cfa
Author: Ian Rogers <irogers@google.com>

tools scripts: Short-circuit CC_NO_CLANG compiler probe in Makefile.include

This commit wraps the CC_NO_CLANG evaluation in a conditional check and exports
it. This caching prevents Make from re-executing the compiler probe multiple
times during incremental builds.

> diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
> index 41971a68972dd..3c7803122ae21 100644
> --- a/tools/scripts/Makefile.include
> +++ b/tools/scripts/Makefile.include
[ ... ]
> @@ -74,7 +74,10 @@ $(call allow-override,CXX,$(CROSS_COMPILE)g++)
>  $(call allow-override,STRIP,$(CROSS_COMPILE)strip)
>  endif
>  
> +ifeq ($(CC_NO_CLANG),)

Does this empty check run the risk of blindly trusting the external shell
environment? If CC_NO_CLANG happens to be exported in the user's shell,
the probe is completely skipped. Would checking the origin of the variable,
such as using ifeq ($(origin CC_NO_CLANG), undefined), prevent this from
causing unintended build misconfigurations?

>  CC_NO_CLANG := $(shell $(CC) -dM -E -x c /dev/null | grep -Fq "__clang__"; echo $$?)
> +endif
> +export CC_NO_CLANG

Could exporting CC_NO_CLANG cause regressions during cross-compilation
when CC and HOSTCC use different compilers?

Many tools build host components by invoking sub-makes with an overridden
compiler, like CC="$(HOSTCC)" in tools/objtool or libsubcmd. Because
CC_NO_CLANG is exported here, these sub-makes will inherit the parent's
cached value and skip their own compiler probes.

If CC=gcc and HOSTCC=clang, the sub-make will inherit CC_NO_CLANG=1,
which incorrectly appends GCC-specific flags (like -Wstrict-aliasing=3)
for the Clang build, potentially breaking it. Conversely, if CC=clang
and HOSTCC=gcc, sub-makes might inherit CC_NO_CLANG=0 and attempt
to use Clang-specific flags like --target= with GCC.

>  
>  ifneq ($(LLVM),)
>  HOSTAR  ?= $(LLVM_PREFIX)llvm-ar$(LLVM_SUFFIX)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260512174638.120445-1-irogers@google.com?part=4