-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no-std friendly test suite #155
Conversation
it now uses the CARGO_CFG_TARGET variables provided by Cargo
there are no intrinsics for float equality atm, so transmute to an integer before comparing
to reduce build time for the most common case of not running tests
travis now installs rust using rustup
I'm trying to debug this crash from the MIPS build job:
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. |
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. |
So, I ignored the divti3 on MIPS to see if the other i128 tests pass I got this assertion while testing the modti3 intrinsic:
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");
}
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. |
there's an unfixed bug. See #137
on Windows, these intrinsics return a U64x2 type because of ABI requirements
This reverts commit 46085a2.
@bors r=alexcrichton |
📌 Commit ffcff00 has been approved by |
🔒 Merge conflict |
@bors r+ |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit ffcff00 has been approved by |
@bors r=alexcrichton |
📌 Commit 44e5a1a has been approved by |
🔒 Merge conflict |
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.