Initial implementation of multitester
Implements part of #72.
I wanted to work on this first because it should help me find the problem in the add implementation.
Test failures now look like this:
```
__addsf3 - Args: 1 1264853201
rustc-builtins: Some(0)
compiler_rt: Some(14950609)
gcc_s: None
__addsf3 - Args: 1 632426600
rustc-builtins: Some(0)
compiler_rt: Some(0.00000000000000030889195)
gcc_s: None
__addsf3 - Args: 1 316213300
rustc-builtins: Some(0)
compiler_rt: Some(0.0000000000000000000000000013696648)
gcc_s: None
[snip]
thread 'float::add::tests::_test::__addsf3' panicked at '[quickcheck] TEST FAILED. Arguments: (1, 1)', /home/matt/.cargo/registry/src/github.com-1ecc6299db9ec823/quickcheck-0.3.1/src/tester.rs:118
```
It currently prints all of the errors, if that's undesirable we'd need to remove the shrinkers or modify quickcheck.
due to how Cargo works, the rustc-cfg in build.rs was picking our target
specifications rather than the one the user meant to use. Placing our
target files in any place other than the root of the Cargo project
avoids the issue.
notable changes in the docker-based testing infrastructure
- the docker containers can now modify $CARGO_HOME, to re-use the outer
Cargo registry, and the target directory to re-use build artifacts.
- the docker containers are removed when their execution finishes
because it's no longer necessary to re-start them to inspect them
because all the interesting output is in the outer target directory
This commit moves over most of the testing infrastructure to in-tree docker
images that are all dispatched to from Travis (no other test configuration).
This allows versioning modifications to the test infrastructure as well as the
code itself. Additionally separate docker images allows for easy modification of
one without worrying about tampering of others as well as easy addition of new
targets by simply adding a new `Dockerfile`.
Additionally this commit bundles the master version of the `compiler-rt` source
repository from `llvm-mirror/compiler-rt` to test against. The compiler-rt
library itself is compiled as a `cdylib` which is then dynamically located at
runtime and we look for symbols in. There's a few hoops here, but they currently
get the job done.
All tests now execute against both gcc_s and compiler-rt, and this
testing strategy is now all hidden behind a macro as well (refactoring
all existing tests along the way).
test our implementations against gcc_s
if it exposes the same intrinsics that we implement -- gcc_s doesn't
implement all the intrinsics for all the architectures.
closes#65
r? @Amanieu
Tested on Linux x86_64 and against the x86_64 and the arm-gnueabi targets. Unclear whether this works on osx or windows.
instead test half of the time against gcc_s and the other half test
against the native operation (\*).
(\*) Not all the targets have available a native version of the
intrinsics under test. On those targets we'll end up testing our
implementation against itself half of the time. This is not much of a
problem because we do several quickcheck runs per intrinsic.
