Different NaN types on mipsel and mips64el than on most other architectures

[silwol]

The following tests fail on mipsel and mips64el architectures while succeeding most others.

#[cfg(test)]
mod tests {
    #[test]
    fn min() {
        assert_eq!(1f64.min(std::f64::NAN), 1f64);
    }
    #[test]
    fn max() {
        assert_eq!(1f64.max(std::f64::NAN), 1f64);
    }
}

It succeeded on mipsel up to stable 1.36.0 rustc, and started failing in 1.37.0 and newer. I'll attempt to use cargo-bisect-rustc track down the exact nightly version that introduced the change (might take some time because it's a qemu vm that is rather slow).

#52897 (comment) was where the initial discussion started, but it seems to be worth a separate issue instead of creating noise there.

It looks as if the failing platforms have a signaling NAN (sNAN) in opposite to the succeeding ones with a quiet NAN (qNAN).

[est31]

Note that this is a valid bug because it violates what that the docs of the min function say:

If one of the arguments is NaN, then the other argument is returned.

See also my comments in that thread for some investigations.

[nagisa]

Both tests pass on actual mips64el hardware (Cavium Octeon II V0.1), as tested with rustc 1.38.0 (625451e37 2019-09-23).

EDIT: both with and without optimisations.

[silwol]

I didn't get cargo-bisect-rustc running properly, as it seems to be targeted at compile-time errors, and with the other attepmts (adding -- test, or running a script) it always told me that the regression was present in the start version already.
None the less, I bisected manually, and the first nightly which fails in my VM is nightly-2019-06-08-mipsel-unknown-linux-gnu - rustc 1.37.0-nightly (d132f544f 2019-06-07). d132f54 doesn't have anything to do with float numbers, but one of it's nearest ancestors, c5295ac, looks like it might be the commit that changed the behavior.
@nagisa I'm not familiar with mips* hardware, but maybe newer processors changed behavior to match IEEE 754-2008 behavior? Before that, the signaling bit wasn't defined in the spec according to #52897 (comment).
The test where I discovered the problem fails for me on a qemu mipsel malta VM, as well as on build hosts provided by Debian (mipsel, mips64el), which are Rhino Labs UTM8 according to the wiki pages describing them. By incident it didn't get queued on any other type of machine.

[est31]

Hmmm indeed c5295ac looks very much related. These are the changes in the compiler-builtins repo: rust-lang/compiler-builtins@0.1.15...0.1.16 . These are the changes in libm: rust-lang/libm@0ae4428...01bee72 . This is the PR that added Rust float min/max functions: #42430. I can't find anything suspicious, in fact it should just have moved the code from one place to another.

The next thing to investigate would probably be the codegen changes. This is the 1.36 output while this is the 1.37 output (both with optimizations enabled). IDK how one can get godbolt to show the fmaxf implementation. @silwol do you get the bug in release mode or only in debug mode?

[silwol]

@est31 Hadn't thought about checking whether it has something to do with build mode. Just tested, it only fails in debug build mode, and succeeds in release build mode.

[est31]

it only fails in debug build mode, and succeeds in release build mode.

Thanks that's consistent with the output of godbolt I linked above, as there the compiler just optimizes out the checks.