1.96 beta regressions involving floats

[theemathas]

The following regressions are found by the 1.96 beta crater run. They involve floats in one way or another.

• https://crater-reports.s3.amazonaws.com/beta-1.96-3/beta-2026-04-21/reg/casper-wasmi-core-0.3.0/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.96-3/beta-2026-04-21/reg/soroban-wasmi_core-0.16.0-soroban2/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.96-3/beta-2026-04-21/reg/raekna-compute-0.2.1/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.96-3/beta-2026-04-21/reg/simdeez-3.0.1/log.txt

The casper-wasmi-core and soroban-wasmi_core regressions are minimized to the following code, whose assertion passes on stable, but fails on beta.

fn main() {
    assert_eq!((-0.0_f32).min(0.0_f32).to_bits(), 0x8000_0000_u32);
}

The raekna-compute regression is minimized to the following code, whose assertion passes on stable, but fails on beta.

fn main() {
    assert_eq!(11.0_f64.acosh(), 3.0889699048446033_f64);
}

I have not yet minimized the simdeez regression, but it seems to involve SIMD and acosh.

[bjorn3]

The docs of min state:

If the inputs compare equal (such as for the case of +0.0 and -0.0), either input may be returned non-deterministically.

So casper-wasmi-core and soroban-wasmi_core were already wrong to assert a specific answer before.

The docs of acosh state:

Unspecified precision

The precision of this function is non-deterministic. This means it varies by platform, Rust version, and can even differ within the same execution from one invocation to the next.

So raekna-compute was already wrong too.

[theemathas]

Minimization of the simdeez regression:

fn main() {
    assert_eq!(3.4028235e38_f32.acosh(), f32::INFINITY);
    assert_eq!(1.7976931348623157e308_f64.acosh(), f64::INFINITY);
}

On stable, both asserts succeed. On beta, each individual assert fails.

(There are other test failures that I didn't minimize, since they involve precision changes.)

[cuviper]

fn main() {
    assert_eq!(3.4028235e38_f32.acosh(), f32::INFINITY);
    assert_eq!(1.7976931348623157e308_f64.acosh(), f64::INFINITY);
}

I think these are still precision errors due to MAX inputs -- they used to overflow to infinity, probably in some intermediate calculation, but once you saturate it can't really come back. Now we get 89.415985 and 710.4758600739439, and I confirmed with Wolfram Alpha that these are correct (within some rounding error).

[cuviper]

The acosh infinity change was deliberate in #154051 to fix #153878.

[theemathas]

The min change is presumably due to #153343.

Do changes like #153343 and #154051 normally need an FCP?

[cuviper]

Do changes like #153343 and #154051 normally need an FCP?

Not when they're within the documented guarantees (or lack thereof) and also not making any new guarantees.

[theemathas]

Closing as intended breakage.