Repository navigation
1.96 beta regressions involving floats #156039
Description
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.
Activity
bjorn3 commentedon May 1, 2026
The docs of
minstate:So casper-wasmi-core and soroban-wasmi_core were already wrong to assert a specific answer before.
The docs of
acoshstate:So raekna-compute was already wrong too.
theemathas commentedon May 1, 2026
Minimization of the simdeez regression:
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 commentedon May 2, 2026
I think these are still precision errors due to
MAXinputs -- 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 commentedon May 2, 2026
The
acoshinfinity change was deliberate in #154051 to fix #153878.theemathas commentedon May 2, 2026
The
minchange is presumably due to #153343.Do changes like #153343 and #154051 normally need an FCP?
cuviper commentedon May 3, 2026
Not when they're within the documented guarantees (or lack thereof) and also not making any new guarantees.
theemathas commentedon May 4, 2026
Closing as intended breakage.