public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Schier <nsc@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	linux-kbuild@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 01/14] kbuild: Bump minimum version of LLVM for building the kernel to 17.0.1
Date: Tue, 5 May 2026 17:27:00 +0200	[thread overview]
Message-ID: <afoMRMnSQUwk1eaN@levanger> (raw)
In-Reply-To: <20260428-bump-minimum-supported-llvm-version-to-17-v1-1-81d9b2e8ee75@kernel.org>

On Tue, Apr 28, 2026 at 10:59:07PM -0400, Nathan Chancellor wrote:
> The current minimum version of LLVM for building the kernel is 15.0.0.
> However, there are two deficiencies compared to GCC that were fixed in
> LLVM 17 that are starting to become more noticeable.
> 
> The first was a bug in LLVM's scope checker [1], where all labels in a
> function were validated as potential targets of an asm goto statement,
> even if they were not listed in the asm goto statement as targets. This
> becomes particularly problematic when the cleanup attribute is used, as
> 
>   asm goto(... : label_a);
>   ...
> label_a:
>   ...
>   int var __free(foo);
>   asm goto(... : label_b);
>   ...
> label_b:
>   ...
> 
> will trigger an error since the scope checker will complain that the
> cleanup variable would be skipped when jumping from the first asm goto
> to label_b (which obviously cannot happen). This issue was the catalyst
> for commit e2ffa15b9baa ("kbuild: Disable CC_HAS_ASM_GOTO_OUTPUT on
> clang < 17"). Unfortunately, this issue is reproducible with regular asm
> goto in addition to asm goto with outputs, so that change was not
> entirely sufficient to avoid the issue altogether. As asm goto has
> effectively been required since commit a0a12c3ed057 ("asm goto:
> eradicate CC_HAS_ASM_GOTO") and the usage of the cleanup attribute
> continues to grow across the tree, raising the minimum to a version that
> avoids this issue altogether is a better long term solution than
> attempting to workaround it at every spot where it happens.
> 
> The second issue is an incompatibility with GCC 8.1+ around variables
> marked with const being valid constant expressions for _Static_assert
> and other macros [2]. With GCC 8.1 being the minimum supported version
> since commit 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30"),
> this incompatibility becomes more of a maintenance burden since only
> clang-15 and clang-16 are affected by it.
> 
> Looking at the clang version of various major distributions through
> Docker images, no one should be left behind as a result of this bump, as
> the old ones cannot clear the current minimum of 15.0.0.
> 
>   archlinux:latest              clang version 22.1.3
>   debian:oldoldstable-slim      Debian clang version 11.0.1-2
>   debian:oldstable-slim         Debian clang version 14.0.6
>   debian:stable-slim            Debian clang version 19.1.7 (3+b1)
>   debian:testing-slim           Debian clang version 21.1.8 (3+b1)
>   debian:unstable-slim          Debian clang version 21.1.8 (7+b1)
>   fedora:42                     clang version 20.1.8 (Fedora 20.1.8-4.fc42)
>   fedora:latest                 clang version 21.1.8 (Fedora 21.1.8-4.fc43)
>   fedora:44                     clang version 22.1.1 (Fedora 22.1.1-2.fc44)
>   fedora:rawhide                clang version 22.1.3 (Fedora 22.1.3-1.fc45)
>   opensuse/leap:latest          clang version 17.0.6
>   opensuse/tumbleweed:latest    clang version 21.1.8
>   ubuntu:jammy                  Ubuntu clang version 14.0.0-1ubuntu1.1
>   ubuntu:noble                  Ubuntu clang version 18.1.3 (1ubuntu1)
>   ubuntu:questing               Ubuntu clang version 20.1.8 (0ubuntu4)
>   ubuntu:resolute               Ubuntu clang version 21.1.8 (6ubuntu1)
> 
> 17.0.1 is chosen as the minimum instead of 17.0.0 to ensure that the
> particular version of LLVM 17 has the two aforementioned bugs fixed, as
> the second was fixed during the 17.0.0 release candidate phase and it
> was not until LLVM 18 that LLVM adopted the scheme of x.0.0 being a
> prerelease version and x.1.0 is a release version [3] to help with
> scenarios such as this.
> 
> Link: https://github.com/llvm/llvm-project/commit/f023f5cdb2e6c19026f04a15b5a935c041835d14 [1]
> Link: https://github.com/llvm/llvm-project/commit/0b2d5b967d98375793897295d651f58f6fbd3034 [2]
> Link: https://github.com/llvm/llvm-project/commit/4532617ae420056bf32f6403dde07fb99d276a49 [3]
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Shuah Khan <skhan@linuxfoundation.org>
> Cc: linux-doc@vger.kernel.org
> ---
>  Documentation/process/changes.rst | 2 +-
>  scripts/min-tool-version.sh       | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
> index 9a99037270ff..b9afce768446 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -36,7 +36,7 @@ bindgen (optional)     0.71.1           bindgen --version
>  binutils               2.30             ld -v
>  bison                  2.0              bison --version
>  btrfs-progs            0.18             btrfs --version
> -Clang/LLVM (optional)  15.0.0           clang --version
> +Clang/LLVM (optional)  17.0.1           clang --version
>  e2fsprogs              1.41.4           e2fsck -V
>  flex                   2.5.35           flex --version
>  gdb                    7.2              gdb --version

FTR: The translations
Documentation/translations/{it_IT,pt_BR}/process/changes.rst become now
even more outdated.

Acked-by: Nicolas Schier <nsc@kernel.org>

  reply	other threads:[~2026-05-05 16:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29  2:59 [PATCH 00/14] Bump minimum version of LLVM for building the kernel to 17.0.1 Nathan Chancellor
2026-04-29  2:59 ` [PATCH 01/14] kbuild: " Nathan Chancellor
2026-05-05 15:27   ` Nicolas Schier [this message]
2026-05-05 18:26     ` Daniel Pereira
2026-04-29  2:59 ` [PATCH 02/14] security/Kconfig.hardening: Remove tautological condition from CC_HAS_ZERO_CALL_USED_REGS Nathan Chancellor
2026-05-05 15:28   ` Nicolas Schier
2026-04-29  2:59 ` [PATCH 03/14] security/Kconfig.hardening: Remove tautological condition from FORTIFY_SOURCE Nathan Chancellor
2026-05-05 15:28   ` Nicolas Schier
2026-04-29  2:59 ` [PATCH 04/14] security/Kconfig.hardening: Remove tautological condition from CC_HAS_RANDSTRUCT Nathan Chancellor
2026-05-05 15:28   ` Nicolas Schier
2026-04-29  2:59 ` [PATCH 05/14] arch/Kconfig: Remove tautological conditions from HAS_LTO_CLANG Nathan Chancellor
2026-05-05 15:30   ` Nicolas Schier
2026-04-29  2:59 ` [PATCH 06/14] arch/Kconfig: Remove tautological condition from AUTOFDO_CLANG Nathan Chancellor
2026-04-29 16:43   ` Rong Xu
2026-04-29  2:59 ` [PATCH 07/14] ARM: Drop tautological ld.lld conditions from ARCH_MULTI_V4{,T} Nathan Chancellor
2026-04-29  2:59 ` [PATCH 08/14] riscv: Remove tautological condition from selection of ARCH_SUPPORTS_CFI Nathan Chancellor
2026-04-29  2:59 ` [PATCH 09/14] riscv: Drop tautological condition from TOOLCHAIN_NEEDS_OLD_ISA_SPEC Nathan Chancellor
2026-04-29  2:59 ` [PATCH 10/14] scripts/Makefile.warn: Drop -Wformat handling for clang < 16 Nathan Chancellor
2026-05-05 15:31   ` Nicolas Schier
2026-04-29  2:59 ` [PATCH 11/14] x86/build: Drop unused '-ffreestanding' addition to KBUILD_CFLAGS Nathan Chancellor
2026-04-29 17:24   ` Nathan Chancellor
2026-04-29  2:59 ` [PATCH 12/14] x86/module: Revert "Deal with GOT based stack cookie load on Clang < 17" Nathan Chancellor
2026-04-29  7:10   ` Ard Biesheuvel
2026-04-29  2:59 ` [PATCH 13/14] x86/entry/vdso32: Remove conditional omission of '.cfi_offset eflags' Nathan Chancellor
2026-04-29  3:15   ` H. Peter Anvin
2026-04-29  2:59 ` [PATCH 14/14] kbuild: Remove check for broken scoping with clang < 17 in CC_HAS_ASM_GOTO_OUTPUT Nathan Chancellor
2026-05-05 15:32   ` Nicolas Schier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afoMRMnSQUwk1eaN@levanger \
    --to=nsc@kernel.org \
    --cc=corbet@lwn.net \
    --cc=justinstitt@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox