Assert_eq!() giving weird results with f32/f64 on macOS!

help
21

Here is the relevant output of sysctl -a from the macOS runner:

machdep.cpu.cores_per_package: 3
machdep.cpu.core_count: 3
machdep.cpu.logical_per_package: 3
machdep.cpu.thread_count: 3
machdep.cpu.brand_string: Apple M1 (Virtual)

Full output here:

22

FWIW, I figured out that using assert_eq!(a.to_bits(), b.to_bits()) instead of assert_eq!(a, b) seems to work reliably, even on the MacOS runner.

23

This doesn't really answer the question (why are two floats that are equal not equal?) though. It would be really great if someone with an M1 could reproduce this.

9 Likes
24

I borrowed a friend's M1 macbook pro, and the tests in the last minimized test post passed for me. (passed = no assertion failures after 10-15 minutes of running).
Created a github repo for easy crosschecking.

Maybe this an issue with the virtualization runner only? I tried running many copies of cargo test in separate windows (to get 16 test threads running on 10 physical cores) but it still passed.
@MuldeR, on the macos runner, if you reduce the test to only 3 tests, does it start passing?

$ cargo test
   Compiling assert_eq_floats_aarch64_macos v0.1.0 (/Users/user/git/assert_eq_floats_aarch64_macos)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.19s
     Running unittests src/lib.rs (target/debug/deps/assert_eq_floats_aarch64_macos-9d6130aa2459a5f7)

running 4 tests
test test_float_1a has been running for over 60 seconds
test test_float_1b has been running for over 60 seconds
test test_float_2a has been running for over 60 seconds
test test_float_2b has been running for over 60 seconds
^C

$ cargo -V
cargo 1.93.0-beta.1 (2c283a9a5 2025-12-04)

snip of sysctl -a | grep machdep

machdep.cpu.cores_per_package: 10
machdep.cpu.core_count: 10
machdep.cpu.logical_per_package: 10
machdep.cpu.thread_count: 10
machdep.cpu.brand_string: Apple M1 Pro
2 Likes
25

I borrowed a friend's M1 macbook pro, and the tests in the last minimized test post passed for me. (passed = no assertion failures after 10-15 minutes of running).
Created a github repo for easy crosschecking.

You can add this to your repo, at .github/workflows/ci.yml, to re-produce the issue:

26

In case this is a hardware bug, you could switch off possible offenders, for example simd with export RUSTFLAGS="-C target-feature=-sse"`