Jump threading MIR opt unsoundly uses bitpattern equality for floats

[Chris00]

I tried this code (sorry, I cannot reproduce it without inari ATM):

use inari::{Interval as I, const_interval};

fn f(u: I) -> f64 {
    let t = u.inf() == 0.;
    // let t = u.inf() == -0.;
    // println!("{}", t);
    if t { 1. }
    else { println!("{} {}", u.inf(), u.inf() == 0.);
        u.inf() }
}

fn main() {
    println!("{}", f(const_interval!(0., 0.)));
}

I expected to see this happen: 1

Instead, in --release mode, I got:

-0 true
-0

If I uncomment one of the above commented lines, the code executes correctly.

Meta

This happens with both

rustc --version --verbose:

rustc 1.82.0-nightly (7120fdac7 2024-07-25)
binary: rustc
commit-hash: 7120fdac7a6e55a5e4b606256042890b36067052
commit-date: 2024-07-25
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 18.1.7

and

rustc 1.80.0 (051478957 2024-07-21)
binary: rustc
commit-hash: 051478957371ee0084a7c0913941d2a8c4757bb9
commit-date: 2024-07-21
host: x86_64-unknown-linux-gnu
release: 1.80.0
LLVM version: 18.1.7

[tgross35]

To minimize this, you should try to inline the logic from inari into your code. E.g. type F64X2 = __m128d;, struct Interval { rep: F64X2 }, const_interval is a transumte, etc.

However, what is the reason you believe this to be a compiler/std bug rather than inari? The return -0 logic comes from inari.

[Chris00]

I tried but inlining the code, the program behaves correctly:

use std::{arch::x86_64::*, mem::transmute};

#[derive(Copy, Clone)]
struct I {
    rep: __m128d,
}

impl I {
    fn new(a: f64, b: f64) -> Self {
        Self { rep: unsafe { transmute([-a, b]) } }
    }

    fn inf(self) -> f64 {
        unsafe { transmute::<_, [f64; 2]>(self.rep)[0] }
    }
}


fn f(u: I) -> f64 {
    let t = u.inf() == 0.;
    if t { 1. }
    else { println!("{} {}", u.inf(), u.inf() == 0.);
        u.inf() }
}

fn main() {
    println!("{}", f(I::new(0., 0.)));
}

[tgross35]

If I am understanding the code correctly then transmute::<_, [f64; 2]>(self.rep)[0] is only extract0, the logic from https://github.com/unageek/inari/blob/3660fa09392b90d320f7e6961e52922ed4b0587c/src/numeric.rs#L27-L37 and here https://github.com/unageek/inari/blob/3660fa09392b90d320f7e6961e52922ed4b0587c/src/interval.rs#L65-L67 seems to be missing.

[Chris00]

You are correct, I oversimplified the inlining. The bug can be reproduced with:

use std::{arch::x86_64::*, mem::transmute};

#[derive(Copy, Clone)]
struct I {
    rep: __m128d,
}

impl I {
    fn new(a: f64, b: f64) -> Self {
        Self { rep: unsafe { transmute([-a, b]) } }
    }

    pub(crate) fn inf_raw(self) -> f64 {
        unsafe { - transmute::<_, [f64; 2]>(self.rep)[0] }
    }

    fn inf(self) -> f64 {
        let x = self.inf_raw();
        if x.is_nan() {
            // The empty interval.
            f64::INFINITY
        } else if x == 0.0 {
            -0.0
        } else {
            x
        }
    }
}


fn f(u: I) -> f64 {
    let t = u.inf() == 0.;
    if t { 1. }
    else { println!("{} {}", u.inf(), u.inf() == 0.);
        u.inf() }
}

fn main() {
    println!("{}", f(I::new(0., 0.)));
}

[tgross35]

Reduced some

#![allow(unused)]
use std::{arch::x86_64::*, mem::transmute};
use std::hint::black_box;

fn check(x: f64) -> f64 {
    if x == 0.0 {
        -0.0
    } else {
        1234.0
    }
}

fn main() {
    let f = 0.0;
    let simty: __m128d = unsafe { transmute([-f, f]) };
    let as_f = unsafe { -transmute::<_, [f64; 2]>(simty)[0] };

    if check(as_f) == 0.0 {
        println!("ok");
    } else {
        println!("bug")
    }
}

https://godbolt.org/z/Whh4sh4bn

[tgross35]

What, why is this code fragile?? No simd types required.

pub fn main() {
    let f: f64 = 0.0;
    let as_f = -f;
    println!("{:#018x}", as_f.to_bits());

    let tmp = if -0.0 == 0.0 {
        -0.0
    } else {
        0.0
    };

    if tmp == 0.0 {
        println!("ok");
    } else {
        println!("bug")
    }
}

Prints "ok" by default, "bug" with -O https://godbolt.org/z/soz3jTThr.

Spot checking some versions it seems to show up at 1.78, which aligns with the LLVM18 version bump. Still reproduces on nightly.

This might be a known issue and it might be fixed with the LLVM19 update. Needs some more digging but I'm going to guess LLVM for now.