`f128` `from_bits` / `to_bits` sometimes gets reversed on ppc

[tgross35]

It seems like using transmute causes the upper and lower 64-bit halves to be loaded reversed. More at https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/f128.20system.20libraries.20noncompliant.20platforms/near/438489330

#![feature(f128)]

#[no_mangle]
#[inline(never)]
fn add_entry(a: f128, b: f128) -> f128 {
    a + b
}

fn main() {
    let a = f128::from_bits(0x0);
    let b = f128::from_bits(0x1);
    dbg!(a, b);
    let c = add_entry(a, b);
    dbg!(c);
}

Espected b to print as 0x00000000000000000000000000000001, but with rustc add_test.rs -o add_test.rust --target powerpc64-unknown-linux-gnu -Clinker=powerpc64-linux-gnu-gcc -Ctarget-cpu=pwr9 it instead prints 0x00000000000000010000000000000000.

[tgross35]

@rustbot label +F-f16_and_f128 +A-ABI +T-libs +C-bug -needs-triage +A-llvm

[RalfJung]

If we define f128 to be the corresponding IEEE float format, then the transmute is by definition correct. That float format defines the representation in memory and I think it's endianess must work out exactly the same as u128? Cc @eddyb @jcranmer @Muon

So at first this looks like a platform bug to me. Certainly we'd have to change a lot more than just from_bits / to_bits if this was deemed correct behavior -- codegen and Miri also need to know how to convert between the raw bits an a floating-point value. Do LLVM optimizations do anything to handle this?

[RalfJung]

Are you sure this is not an ABI bug, a mismatch between caller and callee in how the arguments are interpreted? That seems more likely to me than an in-memory float format with mixed endianess.

Does it make any difference if you remove the from_bits call from the equation, and do the transmute inline via a union instead?

#![feature(f128)]

#[no_mangle]
#[inline(never)]
fn add_entry(a: f128, b: f128) -> f128 {
    a + b
}

union U {
    i: u128,
    f: f128,
}

fn main() { unsafe {
    let a = U { i: 0x0 };
    let b = U { i: 0x1 };
    dbg!(a.f, b.f);
    let c = add_entry(a.f, b.f);
    dbg!(c);
} }

[tgross35]

Yeah there is definitely something more going on here, setting opt-level=3 makes the problem go away

[tgross35]

Slightly reduced

$ cat transmute.rs
#![feature(f128)]

fn main() {
    let a = f128::from_bits(0x1);
    dbg!(a);
}
$ rustc transmute.rs --target powerpc64-unknown-linux-gnu -C linker=powerpc64-linux-gnu-gcc -Ctarget-cpu=pwr9 -o transmute.rs.ppc64.pwr9
$ qemu-ppc64 -L /usr/powerpc64-linux-gnu/ transmute.rs.ppc64.pwr9                                                                                                                                                                    
[transmute.rs:5:5] a = 0x00000000000000010000000000000000

Any idea how to narrow further?

[tgross35]

Your suggestion does indeed fix the issue:

$ cat transmute_union.rs                                                                                                                                                                                                             24-05-14 08:15:29
#![feature(f128)]

union U {
    i: u128,
    f: f128,
}

fn main() {
    let a = U { i: 0x1 };
    dbg!(unsafe { a.f });
}
$ rustc transmute_union.rs --target powerpc64-unknown-linux-gnu -C linker=powerpc64-linux-gnu-gcc -Ctarget-cpu=pwr9 -o transmute_union.rs.ppc64.pwr9
$ qemu-ppc64 -L /usr/powerpc64-linux-gnu/ transmute_union.rs.ppc64.pwr9
[transmute_union.rs:10:5] unsafe { a.f } = 0x00000000000000000000000000000001

edit: but turn on -O and it’s borked again. Interesting.

[RalfJung]

Any idea how to narrow further?

I'd define from_bits locally in this crate and add more debugging to see if it's passing arguments to that function where things break, or returning them from that function.