no-std friendly test suite

[japaric]

this PR moves the test suite away from rand and quickcheck by generating the
unit tests on the host rather than on the target. Because the host is usually
x86_64 (which has hardware ops for most of the operations that need intrinsics
on other architectures), we compute the right answer on the host instead of
comparing against the libgcc_s / compiler-rt implementation on the target. With
this change, we can drop the compiler-rt-cdylib and gcc_s subprojects.

Finally we add a target specific dependency on utest, a no-std testing
framework, to additionally run the test suite on the thumb targets.

r? @alexcrichton
cc @mattico
closes #87 (we no longer depend on the rustc-cfg crate)
closes #90 (we now compare against the result of using hardware ops)
closes #136 (compiler-rt-cdylib has been removed)
closes #144 (we are now running tests on the thumb targets)

---

I have tested this locally on x86_64, ARM and the 4 thumb targets. x86_64 and
ARM pass without a problem. On all thumb targets, I had to disable the test of
the powi*f2 intrinsic as other intrinsics are needed to run that intrinsics
(cf. #154). And on thumbv6, I had to disable several tests due to the debug
assertion reported in #150.

[japaric]

I'm trying to debug this crash from the MIPS build job:

test divti3 ... qemu: uncaught target signal 11 (Segmentation fault) - core dumped

but AFAICT, when running this unit test:

#[test]
fn divti3() {
    // A
    for &((a, b), c) in TEST_CASES {
        // B
        let c_ = __divti3(a, b);
        assert_eq!(((a, b), c), ((a, b), c_));
    }
}

the program crashes before reaching the first iteration of the for loop (so it never reaches point B). I thought it could be may due to the size of the TEST_CASES array which contains 10_000 test cases but reducing it to 1 test case still causes the crash. Other unit tests that make use of i128 types, like multi3, work fine so I have no idea what's going on here.

[alexcrichton]

Looks great to me! It'd be nice to reduce the verbosity of the build script, but not critical. r=me when you feel like this should land.

[japaric]

So, I ignored the divti3 on MIPS to see if the other i128 tests pass I got this assertion while testing the modti3 intrinsic:

running 1 test
test modti3 ... FAILED

failures:

---- modti3 stdout ----
        thread 'modti3' panicked at 'assertion failed: `(left == right)` (left: `((-922337203685477580757, -922337203685477580700), -115292150460684697557)`, right: `((-922337203685477580757, -922337203685477580700), -115292150460684697557)`)', /target/mips-unknown-linux-gnu/debug/build/compiler_builtins-86a4e859175c573b/out/modti3.rs:10039

If you can't tell from glancing at it both the LHS and the RHS are exactly equal! Yet the assertion for equality fails.

There doesn't seem to be a problem with equality of i128. That operation doesn't even use an intrinsic on MIPS.

This program works fine on x86_64 and on MIPS:

#![feature(i128_type)]

fn main() {
    let x: ((i128, i128), i128) = ((-922337203685477580757, -922337203685477580700), -115292150460684697557);
    let y: ((i128, i128), i128) = ((-922337203685477580757, -922337203685477580700), -115292150460684697557);

    assert_eq!(x, y);
    println!("OK");
}

$ cargo run
OK

$ cross run --target mips-unknown-linux-gnu
OK

Seems like this could some undefined behavior or ABI problem related to #137 as the div / mod / divmod intrinsics are all related. @est31, do you remember if that problem was MIPS specific? I'm only seeing the problem on 32-bit MIPS but not on MIPS64.

[japaric]

@bors r=alexcrichton

[bors]

📌 Commit ffcff00 has been approved by alexcrichton

[bors]

🔒 Merge conflict

[japaric]

@bors r+

[bors]

💡 This pull request was already approved, no need to approve it again.

• This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.

[bors]

📌 Commit ffcff00 has been approved by japaric

[japaric]

@bors r=alexcrichton

[bors]

📌 Commit 44e5a1a has been approved by alexcrichton

[bors]

🔒 Merge conflict

[japaric]

I don't know what's up with bors but tests have passed on AppVeyor and on Travis so I'm going to merge manually.