add `Div` and `Mul` for `Complex<{float}>` by folkertdev · Pull Request #162832 · rust-lang/rust

folkertdev · 2026-09-15T22:54:08Z

tracking issue: #154023

There are no fallbacks for the libcalls, so Miri will currently fail.

folkertdev · 2026-09-16T08:56:02Z

@bors try jobs=test-various,test-aarch64-apple-,-gnu-nopt-,test-x86_64-mingw-,test-aarch64-msvc-*,test-arm-android

add `Div` and `Mul` for `Complex<{float}>` try-job: test-various try-job: test-aarch64-apple-* try-job: *-gnu-nopt-* try-job: test-x86_64-mingw-* try-job: test-aarch64-msvc-* try-job: test-arm-android

rust-bors · 2026-09-16T12:09:13Z

☀️ Try build successful (CI)
Build commit: 3b59d93 (3b59d930efb08e53dc535d0e705b2564a402ce9b)
Base parent: 28e8a8c (28e8a8c81bf3b37909edac6c2a76e56f30cd492f)

folkertdev · 2026-09-16T14:32:00Z

@RalfJung I'm a bit unsure on how to get Miri to support this. Is this a case where cfg(miri) is OK?

We can add a fn complex_mul<F: Float>(mut a: F, mut b: F, mut c: F, mut d: F) -> Complex<F> implementation based on crate::num::imp::Float and only call it when cfg(miri).

if unlikely(z.re.is_nan() && z.im.is_nan()) {
    cfg_select! {
        miri => complex_mul(a, b, c, d), // use an implementation in core
        _ => $mul(a, b, c, d), // call the libcall
    }
} else {
    z
}

I know you dislike using cfg(miri) but I don't see other good options here.

RalfJung · 2026-09-16T14:48:19Z

Typically we just implement the libcalls in Miri.

folkertdev · 2026-09-16T15:01:20Z

Ok, that should work. We can merge this then and I'll work on a Miri implementation in parallel.

r? tgross35 or @beetrees

rustbot · 2026-09-16T15:01:25Z

tgross35 is currently at their maximum review capacity.
They may take a while to respond.

RalfJung · 2026-09-16T15:08:27Z

@bors try jobs=test-x86_64-gnu-aux

add `Div` and `Mul` for `Complex<{float}>` try-job: test-x86_64-gnu-aux

rust-bors · 2026-09-16T17:46:53Z

☀️ Try build successful (CI)
Build commit: f9b288f (f9b288f412d8bf91cb68eaee520f73e5bdb9410e)
Base parent: e15cecc (e15ceccfc6209c15b6c4bc6352f6ec6bfe579eaa)

tgross35 · 2026-09-17T04:13:50Z

+            #[inline]
+            fn mul(self, rhs: Self) -> Self::Output {
+                let Complex { re: a, im: b } = self;
+                let Complex { re: c, im: d } = rhs;
+
+                let ac = a * c;
+                let bd = b * d;
+                let ad = a * d;
+                let bc = b * c;
+
+                let z = Complex::new(ac - bd, ad + bc);
+
+                // Only call the libcall when both components are NaN.
+                if unlikely(z.re.is_nan() && z.im.is_nan()) { $mul(a, b, c, d) } else { z }
+            }


The comment says pretty much the same thing as the code, it would be helpful to explain why. Also mild preference for cold_path over unlikely since it's stable.

I think the optimization may pay off but it's unfortunate it means repeated work. Not too bad for hard floats but this means e.g. 12 additional function calls if you hit a NaN with f16. I wonder if there's a case to be made that these (and possibly other) libcalls should be preserve_most or preserve_all since stashing the registers is likely the most expensive part of a call.

View changes since the review

I wrote something, and now usecold_path. I'm not sure how much it helps given that the branch is small, but it also serves as documentation that this is an unlikely branch.

And, this ABI etc was designed way before f16 entered the picture, I don't think this will matter much in practice.

I did mean more of a comment about the optimization going on here, i.e. why are we doing some things inline rather than going directly to the libcall

tgross35 · 2026-09-17T04:17:52Z

The fallback is blocked on rust-lang/libs-team#876.

Also I don't think this is blocked on anything, the same mul/div algorithms could be implemented in apfloat for CTFE/miri.

@nia-e

Complex conjugate, negation and default tracking issue: rust-lang#154023 Add several more straightforward (I hope) impls and methods to `Complex`. - `Default` when `T: Default`. For numbers this means `Complex::default` is the unit element with respect to complex addition - `Neg` when `T: Neg`. Maps `a + bi` to `-a - bi`, which can underflow on integers (but this is no different from addition being able to overflow/underflow too - `conjugate` maps `a + bi` to `a - bi` - make `Complex::new` a `const fn`, because why not Complex division and multiplication is in progress in rust-lang#162832. r? @nia-e for continuity (or `r? libs` if you're busy)

@nia-e

Complex conjugate, negation and default tracking issue: rust-lang#154023 Add several more straightforward (I hope) impls and methods to `Complex`. - `Default` when `T: Default`. For numbers this means `Complex::default` is the unit element with respect to complex addition - `Neg` when `T: Neg`. Maps `a + bi` to `-a - bi`, which can underflow on integers (but this is no different from addition being able to overflow/underflow too - `conjugate` maps `a + bi` to `a - bi` - make `Complex::new` a `const fn`, because why not Complex division and multiplication is in progress in rust-lang#162832. r? @nia-e for continuity (or `r? libs` if you're busy)

folkertdev

I have a Miri PR ready to go, but to test it I need the instances to work first.

We can move it into CMSE later, right now there isn't much point to it I think because many other things do not support const.

View changes since this review

@nia-e

Rollup merge of #162865 - folkertdev:complex-conjugate, r=nia-e Complex conjugate, negation and default tracking issue: #154023 Add several more straightforward (I hope) impls and methods to `Complex`. - `Default` when `T: Default`. For numbers this means `Complex::default` is the unit element with respect to complex addition - `Neg` when `T: Neg`. Maps `a + bi` to `-a - bi`, which can underflow on integers (but this is no different from addition being able to overflow/underflow too - `conjugate` maps `a + bi` to `a - bi` - make `Complex::new` a `const fn`, because why not Complex division and multiplication is in progress in #162832. r? @nia-e for continuity (or `r? libs` if you're busy)

tgross35

r=me with a rebase and optional comment update. Make sure to update the tracking issue API summary, probably going to get easy to lose track

View changes since this review

tgross35 · 2026-09-17T19:24:38Z

+            #[inline]
+            fn mul(self, rhs: Self) -> Self::Output {
+                let Complex { re: a, im: b } = self;
+                let Complex { re: c, im: d } = rhs;
+
+                let ac = a * c;
+                let bd = b * d;
+                let ad = a * d;
+                let bc = b * c;
+
+                let z = Complex::new(ac - bd, ad + bc);
+
+                // Only call the libcall when both components are NaN.
+                if unlikely(z.re.is_nan() && z.im.is_nan()) { $mul(a, b, c, d) } else { z }
+            }


I did mean more of a comment about the optimization going on here, i.e. why are we doing some things inline rather than going directly to the libcall

folkertdev · 2026-09-18T17:53:05Z

@bjorn3 so this hits rust-lang/rustc_codegen_cranelift#1703, how should I disable this test for cranelift (for now, until that bug is fixed)?

linkmauve · 2026-09-27T23:06:52Z

+}
+
+#[test]
+fn div() {


For consistency, you probably want to rename this function:

Suggested change

fn div() {

fn complex_division() {

View changes since the review

linkmauve · 2026-09-27T23:11:10Z

+                let ad = a * d;
+                let bc = b * c;
+
+                let z = Complex::new(ac - bd, ad + bc);


Would it make sense to use algebraic operators here in case $ty is {float}? This would make it possible to use FMA and FMS instructions on architectures which have those, such as ARM.

View changes since the review

I don't think we should go with algebraic operators here - it is good to limit the maximum possible error, and algebraic operators don't have any accuracy guarantees at all.

mul_add_relaxed could technically be used once that PR lands. But I think it's good to have a consistent result across platforms until we figure out exactly what we can say about allowed imprecision.

bjorn3 · 2026-09-28T09:01:34Z

how should I disable this test for cranelift (for now, until that bug is fixed)?

You can write a patch file for and call it compiler/rustc_codegen_cranelift/patches/0029-sysroot_tests-Disable-complex-type-tests.patch.

folkertdev · 2026-09-28T09:23:39Z

A cranelift version with the fix is already out. If that isn't too difficult to upgrade to then I'm fine with waiting a couple more days.

bjorn3 · 2026-09-28T09:27:25Z

bytecodealliance/wasmtime#14361 missed the cutoff for the last Cranelift release (a release branch is cut on the 5th of the month, and then on the 20th it is released). In addition there is a regression in the last release on macOS that I still need to investigate, blocking the upgrade.

rustbot · 2026-09-28T17:16:34Z

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

rustbot · 2026-09-28T17:16:38Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

folkertdev · 2026-09-28T17:16:53Z

@bors try jobs=test-x86_64-msvc-2

add `Div` and `Mul` for `Complex<{float}>` try-job: test-x86_64-msvc-2

rust-bors · 2026-09-28T19:53:31Z

☀️ Try build successful (CI)
Build commit: a4ba2b9 (a4ba2b9e418f5c5d7f4d56845b578eb7afdbd3eb)
Base parent: 77027b6 (77027b64d82d1e92f9ce2ea9042081c4567f5524)

folkertdev · 2026-09-28T20:36:28Z

I've added the .diff, it's tiny, and we can remove it when we do upgrade to a cranelift version that has the fix.

@bors r=tgross35

rust-bors · 2026-09-28T20:36:32Z

📌 Commit 5931727 has been approved by tgross35

It is now in the queue for this repository.

…ss35 add `Div` and `Mul` for `Complex<{float}>` tracking issue: rust-lang#154023 There are no fallbacks for the libcalls, so Miri will currently fail.

…uwer Rollup of 9 pull requests Successful merges: - #162655 (next solver: prefer to select impl candidates over global where-clause candidates) - #162832 (add `Div` and `Mul` for `Complex<{float}>`) - #162862 (Fix intra doc link resolution when a doc comment is composed of both inner and outer doc comment) - #163024 (Add `Dir` equivalents of `fs::metadata` & `fs::symlink_metadata`) - #163200 (make `RustaceansAreAwesome` satisfy trait bounds) - #163210 (std: split stack overflow module) - #163331 (Move `Arc` and `Rc` into `rcs` mod) - #163183 (Add .seek_read_buf_exact() to std::os::windows::fs::FileExt) - #163450 (Force the correct type variable to never for method resolution on an adjusted never type)

…uwer Rollup of 9 pull requests Successful merges: - #158997 (Avoid recording unnameable `extern crate` aliases in diagnostic metadata) - #162655 (next solver: prefer to select impl candidates over global where-clause candidates) - #162832 (add `Div` and `Mul` for `Complex<{float}>`) - #162862 (Fix intra doc link resolution when a doc comment is composed of both inner and outer doc comment) - #163200 (make `RustaceansAreAwesome` satisfy trait bounds) - #163210 (std: split stack overflow module) - #163331 (Move `Arc` and `Rc` into `rcs` mod) - #163183 (Add .seek_read_buf_exact() to std::os::windows::fs::FileExt) - #163450 (Force the correct type variable to never for method resolution on an adjusted never type)

Rollup merge of #162832 - folkertdev:complex-mul-div, r=tgross35 add `Div` and `Mul` for `Complex<{float}>` tracking issue: #154023 There are no fallbacks for the libcalls, so Miri will currently fail.

…uwer Rollup of 9 pull requests Successful merges: - rust-lang/rust#158997 (Avoid recording unnameable `extern crate` aliases in diagnostic metadata) - rust-lang/rust#162655 (next solver: prefer to select impl candidates over global where-clause candidates) - rust-lang/rust#162832 (add `Div` and `Mul` for `Complex<{float}>`) - rust-lang/rust#162862 (Fix intra doc link resolution when a doc comment is composed of both inner and outer doc comment) - rust-lang/rust#163200 (make `RustaceansAreAwesome` satisfy trait bounds) - rust-lang/rust#163210 (std: split stack overflow module) - rust-lang/rust#163331 (Move `Arc` and `Rc` into `rcs` mod) - rust-lang/rust#163183 (Add .seek_read_buf_exact() to std::os::windows::fs::FileExt) - rust-lang/rust#163450 (Force the correct type variable to never for method resolution on an adjusted never type)

folkertdev added the F-complex_numbers `#![feature(complex_numbers)]` label Sep 15, 2026

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 15, 2026