Commit Graph

63 Commits

Author SHA1 Message Date
James Duley ee0aacf4be mul.rs: use wrapping_mul not plain
rustc in debug mode with a plain multiplication will call @llvm.umul.with.overflow.* which may call the builtin resulting in infinite recursion.
2017-01-02 22:57:38 +13:00
Christopher Serr 4733417140 Fix a few clippy warnings 2016-10-16 13:53:31 +02:00
Jorge Aparicio a163ca7ac3 fix more warnings 2016-10-10 20:21:11 -05:00
Jorge Aparicio e05caa1227 fix warnings 2016-10-10 19:45:34 -05:00
Jorge Aparicio c82403551d fix unsafe warnings 2016-10-07 18:19:40 -05:00
Jorge Aparicio fd69beba29 get profile.dev (-debug-assertions) + LTO working 2016-10-07 18:19:40 -05:00
Jorge Aparicio a21fb956f9 insert more `abort()` calls where division by zero may occur 2016-10-07 18:19:40 -05:00
Jorge Aparicio 534d22e287 panic! -> abort
closes #79
2016-10-07 18:19:40 -05:00
Jorge Aparicio f77ca915c4 add an opt-in cargo feature to build intrinsics from compiler-rt source
closes #63
cc #66
2016-09-29 16:06:24 -05:00
Alex Crichton 8e161a791a Expand and refactor teting infrastructure
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).
2016-09-28 22:09:55 -07:00
Jorge Aparicio 384c48ce9b don't test always against gcc_s
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.
2016-09-21 21:38:06 -05:00
Jorge Aparicio 9493c37455 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
2016-09-16 15:53:14 -05:00
Matt Ickstadt 6f0d50ebea Move integer functions to separate module 2016-08-20 15:55:06 -05:00