Conversion from&to float<->integer

[japaric]

this is a rebased version of #139

cc @ithinuel

[mattico]

Can close #106 also once this is merged.

We could probably use a macro to impl the Float trait just like the Int trait, but that can be done in a followup PR.

[japaric]

I can reproduce the powerpc segfault (inside QEMU) locally and consistently. It could be a QEMU bug as I have had segfaults like this with QEMUlated powerpc targets before; though, those were spurious.

[japaric]

FWIW, I can repro the segfault with Cross, which uses QEMU 2.7.1. The CI here is using QEMU 2.6.1. Interestingly, I don' see the segfault if I run the test suite in release mode.

Also given the error message

test float::conv::tests::_test::__fixdfdi ... Invalid instruction

This could be a problem with the default cpu / architecture-level that QEMU uses. Perhaps, we just have to pick a different cpu model in QEMU.

[oli-obk]

Does the architecture need to be changed here or in cross?

[japaric]

@oli-obk Here, this repo doesn't use Cross. I tried a few different QEMU_CPUs last time and none fixed the problem.

[japaric]

rust-lang/rust#41080 appears to have fixed the powerpc segfault (according to my local test). I'll retry once a new nightly becomes available.

[japaric]

Nightly's out. Let's try this.

@bors r+

[bors]

📌 Commit 4c556dc has been approved by japaric

[bors]

⌛ Testing commit 4c556dc with merge dbfcc16...

[bors]

💔 Test failed - status-travis

[oli-obk]

Getting undefined symbols now

[japaric]

I think that was a cache problem as I can't repro locally and AppVeyor passed plus I think I have seen this kind of error beofer. I have cleared the caches. Let's try again.

@bors retry

[bors]

⌛ Testing commit 4c556dc with merge 9db9a8f...

[bors]

💔 Test failed - status-travis

[japaric]

---- float::conv::tests::_test::__fixsfdi stdout ----
__fixsfdi - Args: 9223372000000000000
compiler-builtins: Some(9223372036854775807)
compiler_rt: Some(-9223372036854775808)
gcc_s: Some(Some(-9223372036854775808))

It seems that we indeed are getting the wrong answer on powerpc64le.

use std::mem;

fn main() {
    let x: u32 = 9223372000000000000;
    let y: f32 = unsafe { mem::transmute(x) };
    let z = y as i64;
    println!("f32: {}", y);
    println!("i64: {}", z);
}

# x86_64
$ cargo run
f32: 242691860000000000000000000
i64: -9223372036854775808

But it seems that the intrinsics we are currently shipping with today's std are wrong too (?)

$ cross run --target aarch64-unknown-linux-gnu
f32: 242691860000000000000000000
i64: 9223372036854775807

$ cross run --target powerpc64le-unknown-linux-gnu
f32: 242691860000000000000000000
i64: 9223372036854775807

I'm not sure what's going on there.

[japaric]

Oh, wait. That value doesn't fit in the i64 so this is undef in LLVM. We shouldn't be testing undef conversions.

[japaric]

@bors r+

[bors]

📌 Commit 109c33e has been approved by japaric

[bors]

⌛ Testing commit 109c33e with merge 28ac490...

[japaric]

Cancelling Travis builds that won't be used by bors.

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: japaric
Pushing 28ac490 to master...