The LLVM argument is documented to accept one of three forms:
* a literal '1' to use the default 'clang',
* a toolchain prefix path, ending in a trailing '/',
* a version suffix.

All other values are silently treated as '1'. If for example
the user accidentally forgets the trailing '/' of a toolchain prefix,
kbuild will unexpectedly and silently fall back to the system toolchain.

Instead report an error if the user specified an invalid value for LLVM.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index e404e4767944..2a085a1b6875 100644
--- a/Makefile
+++ b/Makefile
@@ -447,6 +447,8 @@ ifneq ($(filter %/,$(LLVM)),)
 LLVM_PREFIX := $(LLVM)
 else ifneq ($(filter -%,$(LLVM)),)
 LLVM_SUFFIX := $(LLVM)
+else ifneq ($(LLVM),1)
+$(error Invalid value for LLVM=)
 endif
 
 HOSTCC	= $(LLVM_PREFIX)clang$(LLVM_SUFFIX)

---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20260111-kbuild-llvm-arg-c7346a4f2b3a

Best regards,
-- 
Thomas Weißschuh <linux@weissschuh.net>

On Mon, Jan 12, 2026 at 07:43:52AM +0100, Thomas Weißschuh wrote:
> The LLVM argument is documented to accept one of three forms:
> * a literal '1' to use the default 'clang',
> * a toolchain prefix path, ending in a trailing '/',
> * a version suffix.
> 
> All other values are silently treated as '1'. If for example
> the user accidentally forgets the trailing '/' of a toolchain prefix,
> kbuild will unexpectedly and silently fall back to the system toolchain.

Yeah, I do not think falling back to the system toolchain is great here.
This would also catch misuse of LLVM=0, since that is treated as LLVM=1,
rather than reverting to GCC + binutils.

> Instead report an error if the user specified an invalid value for LLVM.
> 
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
>  Makefile | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index e404e4767944..2a085a1b6875 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -447,6 +447,8 @@ ifneq ($(filter %/,$(LLVM)),)
>  LLVM_PREFIX := $(LLVM)
>  else ifneq ($(filter -%,$(LLVM)),)
>  LLVM_SUFFIX := $(LLVM)
> +else ifneq ($(LLVM),1)
> +$(error Invalid value for LLVM=)

If having a hard error is untenable (I am not sure that it is), we could
just warn. Pointing to Documentation/kbuild/llvm.rst might be worthwhile
in the message as well.

>  endif
>  
>  HOSTCC	= $(LLVM_PREFIX)clang$(LLVM_SUFFIX)
> 
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20260111-kbuild-llvm-arg-c7346a4f2b3a
> 
> Best regards,
> -- 
> Thomas Weißschuh <linux@weissschuh.net>
> 
> 

On Mon, Jan 12, 2026 at 04:16:24PM -0700, Nathan Chancellor wrote:
> On Mon, Jan 12, 2026 at 07:43:52AM +0100, Thomas Weißschuh wrote:
> > The LLVM argument is documented to accept one of three forms:
> > * a literal '1' to use the default 'clang',
> > * a toolchain prefix path, ending in a trailing '/',
> > * a version suffix.
> > 
> > All other values are silently treated as '1'. If for example
> > the user accidentally forgets the trailing '/' of a toolchain prefix,
> > kbuild will unexpectedly and silently fall back to the system toolchain.
> 
> Yeah, I do not think falling back to the system toolchain is great here.
> This would also catch misuse of LLVM=0, since that is treated as LLVM=1,
> rather than reverting to GCC + binutils.
> 
> > Instead report an error if the user specified an invalid value for LLVM.
> > 
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > ---
> >  Makefile | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/Makefile b/Makefile
> > index e404e4767944..2a085a1b6875 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -447,6 +447,8 @@ ifneq ($(filter %/,$(LLVM)),)
> >  LLVM_PREFIX := $(LLVM)
> >  else ifneq ($(filter -%,$(LLVM)),)
> >  LLVM_SUFFIX := $(LLVM)
> > +else ifneq ($(LLVM),1)
> > +$(error Invalid value for LLVM=)
> 
> If having a hard error is untenable (I am not sure that it is), we could
> just warn. Pointing to Documentation/kbuild/llvm.rst might be worthwhile
> in the message as well.

I second to have a hard error here with the documentation pointer to
prevent building with an unexpected toolchain, and as there is also no
fallback for gcc toolchains.

Kind regards,
Nicolas

Hi Thomas Weißschuh,

On 2026/1/12 14:43, Thomas Weißschuh wrote:

> The LLVM argument is documented to accept one of three forms:
> * a literal '1' to use the default 'clang',
> * a toolchain prefix path, ending in a trailing '/',
> * a version suffix.
>
> All other values are silently treated as '1'. If for example
> the user accidentally forgets the trailing '/' of a toolchain prefix,
> kbuild will unexpectedly and silently fall back to the system toolchain.
>
> Instead report an error if the user specified an invalid value for LLVM.
>
"Falling back to the system toolchain" may be an acceptable behavior; I 
think reporting a warning here rather than an error would be more 
appropriate.

Thanks,

--

WangYuli

On 2026-01-12 14:58:08+0800, WangYuli wrote:
> Hi Thomas Weißschuh,
> 
> On 2026/1/12 14:43, Thomas Weißschuh wrote:
> 
> > The LLVM argument is documented to accept one of three forms:
> > * a literal '1' to use the default 'clang',
> > * a toolchain prefix path, ending in a trailing '/',
> > * a version suffix.
> > 
> > All other values are silently treated as '1'. If for example
> > the user accidentally forgets the trailing '/' of a toolchain prefix,
> > kbuild will unexpectedly and silently fall back to the system toolchain.
> > 
> > Instead report an error if the user specified an invalid value for LLVM.
> > 
> "Falling back to the system toolchain" may be an acceptable behavior; I
> think reporting a warning here rather than an error would be more
> appropriate.

For which value of 'LLVM' would a silent fallback be the thing to do?


Thomas