LLVM assertions when using -C target-feature=+soft-float with a few targets

269ba41
Opened by Jorge Aparicio at 2023-04-05 17:38:44

Found using smoke. (cc @brson)

Smoke is a "cross" testing framework. It runs different tests, like the unit tests of the standard crates, for several targets. I wanted to see how setting -C target-feature=+soft-float affected a single test case but decided to set it via RUSTFLAGS ~~for fun~~ to see how it affected all the tests it runs. To my surprise, on 6 of 10 targets, this resulted in LLVM assertions while compiling one or two of the many tests that smoke runs. Here's the summary:

  • i686-apple-darwin Assertion: "Should only be an extending load, not truncating!"
  • x86_64-apple-darwin Assertion: "This value type is not natively supported!"
  • i686-unknown-linux-gnu Assertion: "Should only be an extending load, not truncating!"
  • i686-unknown-linux-musl Assertion: "Should only be an extending load, not truncating!"
  • x86_64-unknown-linux-gnu Assertion: "This value type is not natively supported!"
  • x86_64-unknown-linux-musl Assertion: "This value type is not natively supported!"
  • mips-unknown-linux-gnu OK
  • mipsel-unknown-linux-gnu OK
  • powerpc-unknown-linux-gnu OK
  • powerpc64-unknown-linux-gnu OK

And below it's a more detailed report of how the assertion was triggered:

i686-apple-darwin

i686-unknown-linux-gnu

i686-unknown-linux-musl

Travis build job for i686-apple-darwin Travis build job for i686-unknown-linux-gnu Travis build job for i686-unknown-linux-musl

Command:

$ cargo run --target $TARGET --manifest-path libc/libc-test/Cargo.toml

On this rust-lang/libc checkout.

Assertion:

Assertion failed: (MemVT.getScalarType().bitsLT(VT.getScalarType()) && "Should only be an extending load, not truncating!"), function getLoad, file /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp, line 5085.

x86_64-apple-darwin

x86_64-unknown-linux-gnu

x86_64-unknown-linux-musl

Travis build job for x86_64-apple-darwin Travis build job for x86_64-unknown-linux-gnu Travis build job for x86_64-unknown-linux-musl

Command:

$ cargo test --target $TARGET

On this Cargo repository.

Assertion:

rustc: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/include/llvm/Target/TargetLowering.h:437: virtual const llvm::TargetRegisterClass* llvm::TargetLoweringBase::getRegClassFor(llvm::MVT) const: Assertion `RC && "This value type is not natively supported!"' failed.

NOTE cargo test --target $TARGET --release didn't result in a LLVM assertion.

x86_64-unknown-linux-gnu and x86_64-unknown-linux-musl also failed the libc test mentioned in the previous section but with a different LLVM assertion:

rustc: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:4390: llvm::SDValue getMemcpyLoadsAndStores(llvm::SelectionDAG&, const llvm::SDLoc&, llvm::SDValue, llvm::SDValue, llvm::SDValue, uint64_t, unsigned int, bool, bool, llvm::MachinePointerInfo, llvm::MachinePointerInfo): Assertion `NVT.bitsGE(VT)' failed.

Meta

$ rustc -V
rustc 1.13.0-nightly (4f9812a59 2016-09-21)

Final thoughts

I think these assertions could either:

  • Be just badness from mixing the standard crates that were compiled with native float operations enabled with crates that were compiled without them (+soft-float). When we have a Cargo that can build std and (libtest), I should re-run these tests to discard that possibility (std would be recompiled with +soft-float).
  • Indicate that some parts of the standard crates can't be compiled with +soft-float for some targets for some reason.

  1. Thanks for the investigation @japaric! I suspect that +soft-float only makes sense for something like ARM targets (or may be anything not x86) or something like that. We should definitely have a better error here.

    Alex Crichton at 2016-09-27 21:49:34

  2. or may be anything not x86

    I just remember that x86 kernel devs routinely use +soft-float but with other codegen options: something like "-fxsr,-mmx,-sse,-sse2,+soft-float". Perhaps, on x86, you have to use that specific combination of codegen options or you'll hit an LLVM assertion?

    Jorge Aparicio at 2016-09-28 00:25:47

  3. Oh right yeah I remember that now, seems reasonable for a soft-float request to imply those features on x86 to me

    Alex Crichton at 2016-09-28 01:19:32