64 bit shift is broken in nightly build for MIPS

[mcroomp]

I tried this code:

const SHIFTVALUE : i64 = 10000000000i64;

fn main() {

    fn shiftleft(a : i64, b : i64) -> i64 {
        a << b
    }

    assert_eq!(shiftleft(black_box(SHIFTVALUE), black_box(2)), SHIFTVALUE << 2);
}

Nightly fails running on MIPS emulator

assertion left == right failed
left: 35705032704
right: 40000000000

Stable succeeds

Looks like the top and bottom dwords are mixed up

target is mips-unknown-linux-musl
emulator is qemu-mips-static

[nikic]

This is probably related to llvm/llvm-project#64794.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

[saethlin]

This can be provoked on mips64 as well:

use std::hint::black_box;

const SHIFTVALUE: i128 = u64::MAX as i128;

fn main() {
    fn shiftleft(a: i128, b: i128) -> i128 {
        a << b
    }

    assert_eq!(
        shiftleft(black_box(SHIFTVALUE), black_box(2)),
        SHIFTVALUE << 2
    );
}

[matoro]

Is this what's causing these build failures when upgrading from 1.72.0 to 1.73.0? Just checking before I open a new bug.

thread 'rustc' panicked at compiler/rustc_mir_build/src/build/mod.rs:1004:13:
apfloat::ieee::Double gave different result for `3.321928094887362`: 3.3219319068173765(0x400a9351091a8e71) vs Rust's 3.3219280948873622(0x400a934f0979a371)

I get a bunch of these on slightly different floating-point values on mips64.

[saethlin]

Floats are hell, and also this landed with 1.73: #113843

A new issue is a good idea.

[CryZe]

Yeah I've also been getting lots of different floating point related issues on 1.73 on MIPS. I too would've thought they are related to the shifts, but the new apfloat code could also be the reason.

[matoro]

I applied the patch from llvm/llvm-project#64794 (comment) and confirmed that it fixes the 1.73.0 bootstrap problem for me. I also tried the snippet from @saethlin 's comment above and it did not assert after applying that patch.

[Cyanoxygen]

It happened with {u,i}128, too. We stripped down the PoC to a few lines of LLVM IR code, and we reported to the upstream.
Turned out that it is exactly the same problem here.