rust-lang
Test that target feature mix up with homogeneous floats is sound
This pull-request adds a test in src/test/abi/ that test that target feature mix up with homogeneous floats is sound.
This is basically is ripoff of src/test/ui/simd/target-feature-mixup.rs but for floats and without #[repr(simd)].
Extracted from https://github.com/rust-lang/rust/pull/97559 since I don't yet know what to do with that PR.
r? @Mark-Simulacrum
(rust-highfive has picked a reviewer for you, use r? to override)
r? @Amanieu perhaps?
I'm not a huge fan of just running binaries without checking CPUID ahead of time for the relevant target features. I think our CI runs on fairly old CPUs (Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz, in one recent job), which don't have any AVX-512 features, so we'd not be testing this regularly either.
Fundamentally this LGTM. If we absolutely want to make sure that the AVX512 path is tested then we may want to run the test under qemu-x86_64.
Fundamentally this LGTM. If we absolutely want to make sure that the AVX512 path is tested then we may want to run the test under
qemu-x86_64.
Is is required ? Personally I don't it should be, qemu is not perfect and most contributors will run those tests on their machines, so it will get tested as much but still enough to get me to want to integrate it. Having the test is better than not having it at all.
No, I don't think this is strictly required. This test is fine as it is.
@bors r+
:pushpin: Commit 5c6caf34dd46ea0ac3a45654a5db92b6af16ea0b has been approved by Amanieu
It is now in the queue for this repository.
:hourglass: Testing commit 5c6caf34dd46ea0ac3a45654a5db92b6af16ea0b with merge 97c338f2fa6662ed23b3cd8d295a529a8a14487f...
The job dist-i586-gnu-i586-i686-musl failed! Check out the build log: (web) (plain)
Click to see the possible cause of the failure (guessed by this bot)
test [ui] src/test/ui/allocator/two-allocators3.rs ... ok
test [ui] src/test/ui/anon-params/anon-params-denied-2018.rs ... ok
test [ui] src/test/ui/allocator/no_std-alloc-error-handler-default.rs ... ok
test [ui] src/test/ui/allocator/custom.rs ... ok
test [ui] src/test/ui/abi/homogenous-floats-target-feature-mixup.rs ... FAILED
test [ui] src/test/ui/allocator/custom-in-block.rs ... ok
test [ui] src/test/ui/anon-params/anon-params-deprecated.rs ... ok
test [ui] src/test/ui/allocator/custom-in-submodule.rs ... ok
test [ui] src/test/ui/anon-params/anon-params-edition-hygiene.rs ... ok
---
test [ui] src/test/ui/transmutability/primitives/numbers.rs ... ok
failures:
---- [ui] src/test/ui/abi/homogenous-floats-target-feature-mixup.rs stdout ----
error: test run failed!
status: exit status: 101
status: exit status: 101
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/abi/homogenous-floats-target-feature-mixup/a"
stdout: none
--- stderr -------------------------------
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `f32x2(-1.7014118e38, 9.3168e-39)`,
right: `f32x2(1.0, 2.0)`', /checkout/src/test/ui/abi/homogenous-floats-target-feature-mixup.rs:126:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'invalid status at sse: exit status: 101', /checkout/src/test/ui/abi/homogenous-floats-target-feature-mixup.rs:39:9
------------------------------------------
failures:
[ui] src/test/ui/abi/homogenous-floats-target-feature-mixup.rs
test result: FAILED. 13363 passed; 1 failed; 180 ignored; 0 measured; 0 filtered out; finished in 85.84s
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=i586-unknown-linux-gnu
Build completed unsuccessfully in 0:12:37
Wait, never mind. This one failed in CI and wasn't fixed.
I wonder how it got back into the bors queue?
Wait, never mind. This one failed in CI and wasn't fixed.
I wonder how it got back into the bors queue?
Not the first time. It sometimes happens that the queue gets de-synchronized.
Anyway, I looked a bit at the failure and it happen when testing the first sse2 assertion on i586-unknown-linux-gnu. I tried to replicate the failure but didn't yet succeed.
It's maybe related to sse not being available on CI but it would be weird to not get a SIGGILL in that case. Anyone know if the builder dist-i586-gnu-i586-i686-musl uses qemu or something else ?
The i586-unknown-linux-gnu target specifically doesn't enable the sse target feature by default. This means that it passes floating-point arguments via the x87 registers instead of using SSE registers. I expect this might be what is causing the issue here.
I tried pretty hard to reproduce the crash (with/without qemu, with/without mold, with/without native libs, ...) but I'm still unable to reproduce it. It always successfully pass.
I'm not sure what to do or try anymore. Does anyone have an idea?
Can you reproduce the issue with ./x.py test src/test/ui --target=i586-unknown-linux-gnu?
Can you reproduce the issue with
./x.py test src/test/ui --target=i586-unknown-linux-gnu?
Seems like yes, which does not really make sense to me. Anyway this is progress. I will try to investigate this week-end otherwise next week.
I've been unable to find the exact cause of the problem but since src/test/ui/see2.rs manually disable any sse2 test on i586-unknown-linux-gnu, I've done the same and added the same check.
@rustbot ready