All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miguel Ojeda <ojeda@kernel.org>
To: Miguel Ojeda <ojeda@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nicolas Schier <nsc@kernel.org>
Cc: "Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org,
	stable@vger.kernel.org
Subject: [PATCH] rust: kbuild: add intrinsics to fix Rust 1.100.0 builds
Date: Wed,  2 Sep 2026 17:03:53 +0200	[thread overview]
Message-ID: <20260902150353.23666-1-ojeda@kernel.org> (raw)

Starting with Rust 1.100.0 (expected 2026-11-12), a kernel build may
fail at the final link with:

    ld.lld: error: undefined symbol: fmaximum_numf
    >>> referenced by core.1f440ee8661e09f9-cgu.0
    >>>               rust/core.o:(<core::ops::range::RangeFrom<f32> as core::cmp::clamp::ClampBounds<f32>>::clamp) in archive vmlinux.a

(and similar for `f{min,max}imum_num{f,}` and `__gt{s,d}f2`). The issue
reproduces on x86_64 and arm64.

This happens due to upstream Rust commit bd174e1b20a8 ("Implement
clamp_to") [1], which added concrete `ClampBounds` implementations for
floating-point ranges to `core`, and which, in turn, require the compiler
runtime symbols above.

Thus add those intrinsics to our usual workaround, i.e. redirect them
to weak panicking definitions.

Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: https://github.com/rust-lang/rust/commit/bd174e1b20a8 [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
I sent a PR to upstream Rust to make the methods simply `#[inline]`
instead, and it seems like it will be merged, so we can most likely
skip this workaround:

  https://github.com/rust-lang/rust/pull/162191

But I am sending this so that it is archived in the list in case others
hit the same issue meanwhile.

 rust/Makefile             | 4 ++--
 rust/compiler_builtins.rs | 6 ++++++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/rust/Makefile b/rust/Makefile
index da1a7409d984..51e5f83a44b8 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -679,8 +679,8 @@ rust-analyzer:
 		> rust-project.json

 redirect-intrinsics = \
-	__addsf3 __eqsf2 __extendsfdf2 __gesf2 __lesf2 __ltsf2 __mulsf3 __nesf2 __truncdfsf2 __unordsf2 \
-	__adddf3 __eqdf2 __ledf2 __ltdf2 __muldf3 __unorddf2 \
+	__addsf3 __eqsf2 __extendsfdf2 __gesf2 __gtsf2 __lesf2 __ltsf2 __mulsf3 __nesf2 __truncdfsf2 __unordsf2 fmaximum_numf fminimum_numf \
+	__adddf3 __eqdf2 __gtdf2 __ledf2 __ltdf2 __muldf3 __unorddf2 fmaximum_num fminimum_num \
 	__muloti4 __multi3 \
 	__udivmodti4 __udivti3 __umodti3

diff --git a/rust/compiler_builtins.rs b/rust/compiler_builtins.rs
index fc6b54636dd5..31b991e1619d 100644
--- a/rust/compiler_builtins.rs
+++ b/rust/compiler_builtins.rs
@@ -42,21 +42,27 @@ pub extern "C" fn $ident() {
     __eqsf2,
     __extendsfdf2,
     __gesf2,
+    __gtsf2,
     __lesf2,
     __ltsf2,
     __mulsf3,
     __nesf2,
     __truncdfsf2,
     __unordsf2,
+    fmaximum_numf,
+    fminimum_numf,
 });

 define_panicking_intrinsics!("`f64` should not be used", {
     __adddf3,
     __eqdf2,
+    __gtdf2,
     __ledf2,
     __ltdf2,
     __muldf3,
     __unorddf2,
+    fmaximum_num,
+    fminimum_num,
 });

 define_panicking_intrinsics!("`i128` should not be used", {

base-commit: e510334fbaeaa016ac76d80b4c5f47611c5f7860
--
2.55.0

             reply	other threads:[~2026-09-02 15:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 15:03 Miguel Ojeda [this message]
2026-09-04  7:53 ` [PATCH] rust: kbuild: add intrinsics to fix Rust 1.100.0 builds Miguel Ojeda

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=20260902150353.23666-1-ojeda@kernel.org \
    --to=ojeda@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nsc@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=work@onurozkan.dev \
    /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.