All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: akpm@linux-foundation.org, masahiroy@kernel.org
Cc: nicolas@fjasle.eu, linux-kbuild@vger.kernel.org,
	llvm@lists.linux.dev,  patches@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	 Nathan Chancellor <nathan@kernel.org>,
	tglx@linutronix.de, mingo@redhat.com,  bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org,
	 linux@armlinux.org.uk, ardb@kernel.org,
	 linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	 will@kernel.org, mark.rutland@arm.com, mpe@ellerman.id.au,
	 npiggin@gmail.com, aneesh.kumar@kernel.org,
	naveen.n.rao@linux.ibm.com,  linuxppc-dev@lists.ozlabs.org,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	 aou@eecs.berkeley.edu, conor@kernel.org,
	linux-riscv@lists.infradead.org,  keescook@chromium.org,
	linux-hardening@vger.kernel.org
Subject: [PATCH 00/11] Bump the minimum supported version of LLVM to 13.0.1
Date: Thu, 25 Jan 2024 15:55:06 -0700	[thread overview]
Message-ID: <20240125-bump-min-llvm-ver-to-13-0-1-v1-0-f5ff9bda41c5@kernel.org> (raw)

Hi all,

This series bumps the minimum supported version of LLVM for building the
kernel to 13.0.1. The first patch does the bump and all subsequent
patches clean up all the various workarounds and checks for earlier
versions.

Quoting the first patch's commit message for those that were only on CC
for the clean ups:

  When __builtin_mul_overflow() has arguments that differ in terms of
  signedness and width, LLVM may generate a libcall to __muloti4 because
  it performs the checks in terms of 65-bit multiplication. This issue
  becomes harder to hit (but still possible) after LLVM 12.0.0, which
  includes a special case for matching widths but different signs.

  To gain access to this special case, which the kernel can take advantage
  of when calls to __muloti4 appear, bump the minimum supported version of
  LLVM for building the kernel to 13.0.1. 13.0.1 was chosen because there
  is minimal impact to distribution support while allowing a few more
  workarounds to be dropped in the kernel source than if 12.0.0 were
  chosen. Looking at container images of up to date distribution versions:

    archlinux:latest              clang version 16.0.6
    debian:oldoldstable-slim      clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
    debian:oldstable-slim         Debian clang version 11.0.1-2
    debian:stable-slim            Debian clang version 14.0.6
    debian:testing-slim           Debian clang version 16.0.6 (19)
    debian:unstable-slim          Debian clang version 16.0.6 (19)
    fedora:38                     clang version 16.0.6 (Fedora 16.0.6-3.fc38)
    fedora:latest                 clang version 17.0.6 (Fedora 17.0.6-1.fc39)
    fedora:rawhide                clang version 17.0.6 (Fedora 17.0.6-1.fc40)
    opensuse/leap:latest          clang version 15.0.7
    opensuse/tumbleweed:latest    clang version 17.0.6
    ubuntu:focal                  clang version 10.0.0-4ubuntu1
    ubuntu:latest                 Ubuntu clang version 14.0.0-1ubuntu1.1
    ubuntu:rolling                Ubuntu clang version 16.0.6 (15)
    ubuntu:devel                  Ubuntu clang version 17.0.6 (3)

  The only distribution that gets left behind is Debian Bullseye, as the
  default version is 11.0.1; other distributions either have a newer
  version than 13.0.1 or one older than the current minimum of 11.0.0.
  Debian has easy access to more recent LLVM versions through
  apt.llvm.org, so this is not as much of a concern. There are also the
  kernel.org LLVM toolchains, which should work with distributions with
  glibc 2.28 and newer.

  Another benefit of slimming up the number of supported versions of LLVM
  for building the kernel is reducing the build capacity needed to support
  a matrix that builds with each supported version, which allows a matrix
  to reallocate the freed up build capacity towards something else, such
  as more configuration combinations.

This passes my build matrix with all supported versions.

This is based on Andrew's mm-nonmm-unstable to avoid trivial conflicts
with my series to update the LLVM links across the repository [1] but I
can easily rebase it to linux-kbuild if Masahiro would rather these
patches go through there (and defer the conflict resolution to the merge
window).

[1]: https://lore.kernel.org/20240109-update-llvm-links-v1-0-eb09b59db071@kernel.org/

---
Nathan Chancellor (11):
      kbuild: Raise the minimum supported version of LLVM to 13.0.1
      Makefile: Drop warn-stack-size plugin opt
      x86: Drop stack-alignment plugin opt
      ARM: Remove Thumb2 __builtin_thread_pointer workaround for Clang
      arm64: Kconfig: Clean up tautological LLVM version checks
      powerpc: Kconfig: Remove tautology in CONFIG_COMPAT
      riscv: Remove MCOUNT_NAME workaround
      riscv: Kconfig: Remove version dependency from CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE
      fortify: Drop Clang version check for 12.0.1 or newer
      lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV
      compiler-clang.h: Update __diag_clang() macros for minimum version bump

 Documentation/process/changes.rst |  2 +-
 Makefile                          |  8 --------
 arch/arm/include/asm/current.h    |  8 +-------
 arch/arm64/Kconfig                |  5 +----
 arch/powerpc/Kconfig              |  1 -
 arch/riscv/Kconfig                |  2 --
 arch/riscv/include/asm/ftrace.h   | 14 ++------------
 arch/riscv/kernel/mcount.S        | 10 +++++-----
 arch/x86/Makefile                 |  6 ------
 include/linux/compiler-clang.h    |  8 ++------
 lib/Kconfig.debug                 |  2 +-
 scripts/min-tool-version.sh       |  2 +-
 scripts/recordmcount.pl           |  2 +-
 security/Kconfig                  |  2 --
 14 files changed, 15 insertions(+), 57 deletions(-)
---
base-commit: 979741ebd48f75ed6d101c7290e3325340d361ff
change-id: 20240124-bump-min-llvm-ver-to-13-0-1-39f84dd36b19

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: akpm@linux-foundation.org, masahiroy@kernel.org
Cc: nicolas@fjasle.eu, linux-kbuild@vger.kernel.org,
	llvm@lists.linux.dev,  patches@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	 Nathan Chancellor <nathan@kernel.org>,
	tglx@linutronix.de, mingo@redhat.com,  bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org,
	 linux@armlinux.org.uk, ardb@kernel.org,
	 linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	 will@kernel.org, mark.rutland@arm.com, mpe@ellerman.id.au,
	 npiggin@gmail.com, aneesh.kumar@kernel.org,
	naveen.n.rao@linux.ibm.com,  linuxppc-dev@lists.ozlabs.org,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	 aou@eecs.berkeley.edu, conor@kernel.org,
	linux-riscv@lists.infradead.org,  keescook@chromium.org,
	linux-hardening@vger.kernel.org
Subject: [PATCH 00/11] Bump the minimum supported version of LLVM to 13.0.1
Date: Thu, 25 Jan 2024 15:55:06 -0700	[thread overview]
Message-ID: <20240125-bump-min-llvm-ver-to-13-0-1-v1-0-f5ff9bda41c5@kernel.org> (raw)

Hi all,

This series bumps the minimum supported version of LLVM for building the
kernel to 13.0.1. The first patch does the bump and all subsequent
patches clean up all the various workarounds and checks for earlier
versions.

Quoting the first patch's commit message for those that were only on CC
for the clean ups:

  When __builtin_mul_overflow() has arguments that differ in terms of
  signedness and width, LLVM may generate a libcall to __muloti4 because
  it performs the checks in terms of 65-bit multiplication. This issue
  becomes harder to hit (but still possible) after LLVM 12.0.0, which
  includes a special case for matching widths but different signs.

  To gain access to this special case, which the kernel can take advantage
  of when calls to __muloti4 appear, bump the minimum supported version of
  LLVM for building the kernel to 13.0.1. 13.0.1 was chosen because there
  is minimal impact to distribution support while allowing a few more
  workarounds to be dropped in the kernel source than if 12.0.0 were
  chosen. Looking at container images of up to date distribution versions:

    archlinux:latest              clang version 16.0.6
    debian:oldoldstable-slim      clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
    debian:oldstable-slim         Debian clang version 11.0.1-2
    debian:stable-slim            Debian clang version 14.0.6
    debian:testing-slim           Debian clang version 16.0.6 (19)
    debian:unstable-slim          Debian clang version 16.0.6 (19)
    fedora:38                     clang version 16.0.6 (Fedora 16.0.6-3.fc38)
    fedora:latest                 clang version 17.0.6 (Fedora 17.0.6-1.fc39)
    fedora:rawhide                clang version 17.0.6 (Fedora 17.0.6-1.fc40)
    opensuse/leap:latest          clang version 15.0.7
    opensuse/tumbleweed:latest    clang version 17.0.6
    ubuntu:focal                  clang version 10.0.0-4ubuntu1
    ubuntu:latest                 Ubuntu clang version 14.0.0-1ubuntu1.1
    ubuntu:rolling                Ubuntu clang version 16.0.6 (15)
    ubuntu:devel                  Ubuntu clang version 17.0.6 (3)

  The only distribution that gets left behind is Debian Bullseye, as the
  default version is 11.0.1; other distributions either have a newer
  version than 13.0.1 or one older than the current minimum of 11.0.0.
  Debian has easy access to more recent LLVM versions through
  apt.llvm.org, so this is not as much of a concern. There are also the
  kernel.org LLVM toolchains, which should work with distributions with
  glibc 2.28 and newer.

  Another benefit of slimming up the number of supported versions of LLVM
  for building the kernel is reducing the build capacity needed to support
  a matrix that builds with each supported version, which allows a matrix
  to reallocate the freed up build capacity towards something else, such
  as more configuration combinations.

This passes my build matrix with all supported versions.

This is based on Andrew's mm-nonmm-unstable to avoid trivial conflicts
with my series to update the LLVM links across the repository [1] but I
can easily rebase it to linux-kbuild if Masahiro would rather these
patches go through there (and defer the conflict resolution to the merge
window).

[1]: https://lore.kernel.org/20240109-update-llvm-links-v1-0-eb09b59db071@kernel.org/

---
Nathan Chancellor (11):
      kbuild: Raise the minimum supported version of LLVM to 13.0.1
      Makefile: Drop warn-stack-size plugin opt
      x86: Drop stack-alignment plugin opt
      ARM: Remove Thumb2 __builtin_thread_pointer workaround for Clang
      arm64: Kconfig: Clean up tautological LLVM version checks
      powerpc: Kconfig: Remove tautology in CONFIG_COMPAT
      riscv: Remove MCOUNT_NAME workaround
      riscv: Kconfig: Remove version dependency from CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE
      fortify: Drop Clang version check for 12.0.1 or newer
      lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV
      compiler-clang.h: Update __diag_clang() macros for minimum version bump

 Documentation/process/changes.rst |  2 +-
 Makefile                          |  8 --------
 arch/arm/include/asm/current.h    |  8 +-------
 arch/arm64/Kconfig                |  5 +----
 arch/powerpc/Kconfig              |  1 -
 arch/riscv/Kconfig                |  2 --
 arch/riscv/include/asm/ftrace.h   | 14 ++------------
 arch/riscv/kernel/mcount.S        | 10 +++++-----
 arch/x86/Makefile                 |  6 ------
 include/linux/compiler-clang.h    |  8 ++------
 lib/Kconfig.debug                 |  2 +-
 scripts/min-tool-version.sh       |  2 +-
 scripts/recordmcount.pl           |  2 +-
 security/Kconfig                  |  2 --
 14 files changed, 15 insertions(+), 57 deletions(-)
---
base-commit: 979741ebd48f75ed6d101c7290e3325340d361ff
change-id: 20240124-bump-min-llvm-ver-to-13-0-1-39f84dd36b19

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: akpm@linux-foundation.org, masahiroy@kernel.org
Cc: nicolas@fjasle.eu, linux-kbuild@vger.kernel.org,
	llvm@lists.linux.dev,  patches@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	 Nathan Chancellor <nathan@kernel.org>,
	tglx@linutronix.de, mingo@redhat.com,  bp@alien8.de,
	dave.hansen@linux.intel.com, x86@kernel.org,
	 linux@armlinux.org.uk, ardb@kernel.org,
	 linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	 will@kernel.org, mark.rutland@arm.com, mpe@ellerman.id.au,
	 npiggin@gmail.com, aneesh.kumar@kernel.org,
	naveen.n.rao@linux.ibm.com,  linuxppc-dev@lists.ozlabs.org,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	 aou@eecs.berkeley.edu, conor@kernel.org,
	linux-riscv@lists.infradead.org,  keescook@chromium.org,
	linux-hardening@vger.kernel.org
Subject: [PATCH 00/11] Bump the minimum supported version of LLVM to 13.0.1
Date: Thu, 25 Jan 2024 15:55:06 -0700	[thread overview]
Message-ID: <20240125-bump-min-llvm-ver-to-13-0-1-v1-0-f5ff9bda41c5@kernel.org> (raw)

Hi all,

This series bumps the minimum supported version of LLVM for building the
kernel to 13.0.1. The first patch does the bump and all subsequent
patches clean up all the various workarounds and checks for earlier
versions.

Quoting the first patch's commit message for those that were only on CC
for the clean ups:

  When __builtin_mul_overflow() has arguments that differ in terms of
  signedness and width, LLVM may generate a libcall to __muloti4 because
  it performs the checks in terms of 65-bit multiplication. This issue
  becomes harder to hit (but still possible) after LLVM 12.0.0, which
  includes a special case for matching widths but different signs.

  To gain access to this special case, which the kernel can take advantage
  of when calls to __muloti4 appear, bump the minimum supported version of
  LLVM for building the kernel to 13.0.1. 13.0.1 was chosen because there
  is minimal impact to distribution support while allowing a few more
  workarounds to be dropped in the kernel source than if 12.0.0 were
  chosen. Looking at container images of up to date distribution versions:

    archlinux:latest              clang version 16.0.6
    debian:oldoldstable-slim      clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
    debian:oldstable-slim         Debian clang version 11.0.1-2
    debian:stable-slim            Debian clang version 14.0.6
    debian:testing-slim           Debian clang version 16.0.6 (19)
    debian:unstable-slim          Debian clang version 16.0.6 (19)
    fedora:38                     clang version 16.0.6 (Fedora 16.0.6-3.fc38)
    fedora:latest                 clang version 17.0.6 (Fedora 17.0.6-1.fc39)
    fedora:rawhide                clang version 17.0.6 (Fedora 17.0.6-1.fc40)
    opensuse/leap:latest          clang version 15.0.7
    opensuse/tumbleweed:latest    clang version 17.0.6
    ubuntu:focal                  clang version 10.0.0-4ubuntu1
    ubuntu:latest                 Ubuntu clang version 14.0.0-1ubuntu1.1
    ubuntu:rolling                Ubuntu clang version 16.0.6 (15)
    ubuntu:devel                  Ubuntu clang version 17.0.6 (3)

  The only distribution that gets left behind is Debian Bullseye, as the
  default version is 11.0.1; other distributions either have a newer
  version than 13.0.1 or one older than the current minimum of 11.0.0.
  Debian has easy access to more recent LLVM versions through
  apt.llvm.org, so this is not as much of a concern. There are also the
  kernel.org LLVM toolchains, which should work with distributions with
  glibc 2.28 and newer.

  Another benefit of slimming up the number of supported versions of LLVM
  for building the kernel is reducing the build capacity needed to support
  a matrix that builds with each supported version, which allows a matrix
  to reallocate the freed up build capacity towards something else, such
  as more configuration combinations.

This passes my build matrix with all supported versions.

This is based on Andrew's mm-nonmm-unstable to avoid trivial conflicts
with my series to update the LLVM links across the repository [1] but I
can easily rebase it to linux-kbuild if Masahiro would rather these
patches go through there (and defer the conflict resolution to the merge
window).

[1]: https://lore.kernel.org/20240109-update-llvm-links-v1-0-eb09b59db071@kernel.org/

---
Nathan Chancellor (11):
      kbuild: Raise the minimum supported version of LLVM to 13.0.1
      Makefile: Drop warn-stack-size plugin opt
      x86: Drop stack-alignment plugin opt
      ARM: Remove Thumb2 __builtin_thread_pointer workaround for Clang
      arm64: Kconfig: Clean up tautological LLVM version checks
      powerpc: Kconfig: Remove tautology in CONFIG_COMPAT
      riscv: Remove MCOUNT_NAME workaround
      riscv: Kconfig: Remove version dependency from CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE
      fortify: Drop Clang version check for 12.0.1 or newer
      lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV
      compiler-clang.h: Update __diag_clang() macros for minimum version bump

 Documentation/process/changes.rst |  2 +-
 Makefile                          |  8 --------
 arch/arm/include/asm/current.h    |  8 +-------
 arch/arm64/Kconfig                |  5 +----
 arch/powerpc/Kconfig              |  1 -
 arch/riscv/Kconfig                |  2 --
 arch/riscv/include/asm/ftrace.h   | 14 ++------------
 arch/riscv/kernel/mcount.S        | 10 +++++-----
 arch/x86/Makefile                 |  6 ------
 include/linux/compiler-clang.h    |  8 ++------
 lib/Kconfig.debug                 |  2 +-
 scripts/min-tool-version.sh       |  2 +-
 scripts/recordmcount.pl           |  2 +-
 security/Kconfig                  |  2 --
 14 files changed, 15 insertions(+), 57 deletions(-)
---
base-commit: 979741ebd48f75ed6d101c7290e3325340d361ff
change-id: 20240124-bump-min-llvm-ver-to-13-0-1-39f84dd36b19

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Nathan Chancellor <nathan@kernel.org>
To: akpm@linux-foundation.org, masahiroy@kernel.org
Cc: mark.rutland@arm.com, catalin.marinas@arm.com,
	dave.hansen@linux.intel.com, linux-kernel@vger.kernel.org,
	aou@eecs.berkeley.edu, linux-hardening@vger.kernel.org,
	linux-riscv@lists.infradead.org, will@kernel.org,
	ardb@kernel.org, keescook@chromium.org, x86@kernel.org,
	linux@armlinux.org.uk, aneesh.kumar@kernel.org, mingo@redhat.com,
	naveen.n.rao@linux.ibm.com, llvm@lists.linux.dev,
	nicolas@fjasle.eu, linux-kbuild@vger.kernel.org,
	npiggin@gmail.com, Nathan Chancellor <nathan@kernel.org>,
	bp@alien8.de, paul.walmsley@sifive.com, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org, patches@lists.linux.dev,
	conor@kernel.org, palmer@dabbelt.com,
	linuxppc-dev@lists.ozlabs.org
Subject: [PATCH 00/11] Bump the minimum supported version of LLVM to 13.0.1
Date: Thu, 25 Jan 2024 15:55:06 -0700	[thread overview]
Message-ID: <20240125-bump-min-llvm-ver-to-13-0-1-v1-0-f5ff9bda41c5@kernel.org> (raw)

Hi all,

This series bumps the minimum supported version of LLVM for building the
kernel to 13.0.1. The first patch does the bump and all subsequent
patches clean up all the various workarounds and checks for earlier
versions.

Quoting the first patch's commit message for those that were only on CC
for the clean ups:

  When __builtin_mul_overflow() has arguments that differ in terms of
  signedness and width, LLVM may generate a libcall to __muloti4 because
  it performs the checks in terms of 65-bit multiplication. This issue
  becomes harder to hit (but still possible) after LLVM 12.0.0, which
  includes a special case for matching widths but different signs.

  To gain access to this special case, which the kernel can take advantage
  of when calls to __muloti4 appear, bump the minimum supported version of
  LLVM for building the kernel to 13.0.1. 13.0.1 was chosen because there
  is minimal impact to distribution support while allowing a few more
  workarounds to be dropped in the kernel source than if 12.0.0 were
  chosen. Looking at container images of up to date distribution versions:

    archlinux:latest              clang version 16.0.6
    debian:oldoldstable-slim      clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
    debian:oldstable-slim         Debian clang version 11.0.1-2
    debian:stable-slim            Debian clang version 14.0.6
    debian:testing-slim           Debian clang version 16.0.6 (19)
    debian:unstable-slim          Debian clang version 16.0.6 (19)
    fedora:38                     clang version 16.0.6 (Fedora 16.0.6-3.fc38)
    fedora:latest                 clang version 17.0.6 (Fedora 17.0.6-1.fc39)
    fedora:rawhide                clang version 17.0.6 (Fedora 17.0.6-1.fc40)
    opensuse/leap:latest          clang version 15.0.7
    opensuse/tumbleweed:latest    clang version 17.0.6
    ubuntu:focal                  clang version 10.0.0-4ubuntu1
    ubuntu:latest                 Ubuntu clang version 14.0.0-1ubuntu1.1
    ubuntu:rolling                Ubuntu clang version 16.0.6 (15)
    ubuntu:devel                  Ubuntu clang version 17.0.6 (3)

  The only distribution that gets left behind is Debian Bullseye, as the
  default version is 11.0.1; other distributions either have a newer
  version than 13.0.1 or one older than the current minimum of 11.0.0.
  Debian has easy access to more recent LLVM versions through
  apt.llvm.org, so this is not as much of a concern. There are also the
  kernel.org LLVM toolchains, which should work with distributions with
  glibc 2.28 and newer.

  Another benefit of slimming up the number of supported versions of LLVM
  for building the kernel is reducing the build capacity needed to support
  a matrix that builds with each supported version, which allows a matrix
  to reallocate the freed up build capacity towards something else, such
  as more configuration combinations.

This passes my build matrix with all supported versions.

This is based on Andrew's mm-nonmm-unstable to avoid trivial conflicts
with my series to update the LLVM links across the repository [1] but I
can easily rebase it to linux-kbuild if Masahiro would rather these
patches go through there (and defer the conflict resolution to the merge
window).

[1]: https://lore.kernel.org/20240109-update-llvm-links-v1-0-eb09b59db071@kernel.org/

---
Nathan Chancellor (11):
      kbuild: Raise the minimum supported version of LLVM to 13.0.1
      Makefile: Drop warn-stack-size plugin opt
      x86: Drop stack-alignment plugin opt
      ARM: Remove Thumb2 __builtin_thread_pointer workaround for Clang
      arm64: Kconfig: Clean up tautological LLVM version checks
      powerpc: Kconfig: Remove tautology in CONFIG_COMPAT
      riscv: Remove MCOUNT_NAME workaround
      riscv: Kconfig: Remove version dependency from CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE
      fortify: Drop Clang version check for 12.0.1 or newer
      lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV
      compiler-clang.h: Update __diag_clang() macros for minimum version bump

 Documentation/process/changes.rst |  2 +-
 Makefile                          |  8 --------
 arch/arm/include/asm/current.h    |  8 +-------
 arch/arm64/Kconfig                |  5 +----
 arch/powerpc/Kconfig              |  1 -
 arch/riscv/Kconfig                |  2 --
 arch/riscv/include/asm/ftrace.h   | 14 ++------------
 arch/riscv/kernel/mcount.S        | 10 +++++-----
 arch/x86/Makefile                 |  6 ------
 include/linux/compiler-clang.h    |  8 ++------
 lib/Kconfig.debug                 |  2 +-
 scripts/min-tool-version.sh       |  2 +-
 scripts/recordmcount.pl           |  2 +-
 security/Kconfig                  |  2 --
 14 files changed, 15 insertions(+), 57 deletions(-)
---
base-commit: 979741ebd48f75ed6d101c7290e3325340d361ff
change-id: 20240124-bump-min-llvm-ver-to-13-0-1-39f84dd36b19

Best regards,
-- 
Nathan Chancellor <nathan@kernel.org>


             reply	other threads:[~2024-01-25 22:56 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25 22:55 Nathan Chancellor [this message]
2024-01-25 22:55 ` [PATCH 00/11] Bump the minimum supported version of LLVM to 13.0.1 Nathan Chancellor
2024-01-25 22:55 ` Nathan Chancellor
2024-01-25 22:55 ` Nathan Chancellor
2024-01-25 22:55 ` [PATCH 01/11] kbuild: Raise " Nathan Chancellor
2024-01-25 22:55 ` [PATCH 02/11] Makefile: Drop warn-stack-size plugin opt Nathan Chancellor
2024-01-25 22:55 ` [PATCH 03/11] x86: Drop stack-alignment " Nathan Chancellor
2024-01-25 22:55 ` [PATCH 04/11] ARM: Remove Thumb2 __builtin_thread_pointer workaround for Clang Nathan Chancellor
2024-01-25 22:55   ` Nathan Chancellor
2024-01-26  8:44   ` Ard Biesheuvel
2024-01-26  8:44     ` Ard Biesheuvel
2024-01-25 22:55 ` [PATCH 05/11] arm64: Kconfig: Clean up tautological LLVM version checks Nathan Chancellor
2024-01-25 22:55   ` Nathan Chancellor
2024-01-26 12:59   ` Mark Rutland
2024-01-26 12:59     ` Mark Rutland
2024-01-26 16:10     ` Nathan Chancellor
2024-01-26 16:10       ` Nathan Chancellor
2024-01-26 17:00       ` Mark Rutland
2024-01-26 17:00         ` Mark Rutland
2024-01-25 22:55 ` [PATCH 06/11] powerpc: Kconfig: Remove tautology in CONFIG_COMPAT Nathan Chancellor
2024-01-25 22:55   ` Nathan Chancellor
2024-01-25 22:55 ` [PATCH 07/11] riscv: Remove MCOUNT_NAME workaround Nathan Chancellor
2024-01-25 22:55   ` Nathan Chancellor
2024-01-25 22:55 ` [PATCH 08/11] riscv: Kconfig: Remove version dependency from CONFIG_CLANG_SUPPORTS_DYNAMIC_FTRACE Nathan Chancellor
2024-01-25 22:55   ` Nathan Chancellor
2024-01-25 22:55 ` [PATCH 09/11] fortify: Drop Clang version check for 12.0.1 or newer Nathan Chancellor
2024-01-25 23:09   ` Kees Cook
2024-01-25 22:55 ` [PATCH 10/11] lib/Kconfig.debug: Update Clang version check in CONFIG_KCOV Nathan Chancellor
2024-01-25 22:55 ` [PATCH 11/11] compiler-clang.h: Update __diag_clang() macros for minimum version bump Nathan Chancellor
2024-01-25 23:10 ` [PATCH 00/11] Bump the minimum supported version of LLVM to 13.0.1 Kees Cook
2024-01-25 23:10   ` Kees Cook
2024-01-25 23:10   ` Kees Cook
2024-01-25 23:10   ` Kees Cook
2024-03-25  4:42 ` patchwork-bot+linux-riscv
2024-03-25  4:42   ` patchwork-bot+linux-riscv
2024-03-25  4:42   ` patchwork-bot+linux-riscv
2024-03-25  4:42   ` patchwork-bot+linux-riscv

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=20240125-bump-min-llvm-ver-to-13-0-1-v1-0-f5ff9bda41c5@kernel.org \
    --to=nathan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=conor@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=llvm@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=masahiroy@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.ibm.com \
    --cc=nicolas@fjasle.eu \
    --cc=npiggin@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=patches@lists.linux.dev \
    --cc=paul.walmsley@sifive.com \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.