Causes LLVM Error when used in an executable that gets compiled with "+soft-float"

[phip1611]

Hi there! I discovered this error originally in the fontdue crate (mooman219/fontdue#98 (comment)) and created a Rust bug report yesterday (rust-lang/rust#92760). In the meantime, I found out that the error originates in this library, which is a dependency of fontdue.

Minimal example to reproduce:

fn main() {
    let _book_reviews = hashbrown::HashMap::<(), ()>::new();
}

Compile with $ cargo rustc --bin bug -- -C target-feature=+soft-float,-sse,-sse2,-x87
Causes a broken compilation and LLVM ERROR: Do not know how to split this operator's operand!

The bug happens with multiple Rust versions, stable and nightly.

I try to further enclose the actual problem and trace it down to a specific Rust pattern or so. Maybe there will be an easy way to work-a-round this bug in this crate (maybe via a cargo feature) until this bug gets closed in Rustc or LLVM?

[Amanieu]

Flags passed to cargo rustc only apply to the current crate, not its dependencies. You need to set the flags in RUSTFLAGS and then use -Z build-std to rebuild the standard library as well to not use sse instructions.

[phip1611]

To be exactly, I'm using fondue [-> hashbrown] in a no_std executable, that gets build with the build-std-feature of cargo. The compiler target there uses the specified CPU features from above, which should get applied to the crate itself, all dependencies, and the core library. The example above is just my minimal reproducible example.

Therefore, there still must be some bug.

[Amanieu]

It works fine for me:

Cargo.toml

[package]
name = "foo"
version = "0.1.0"
edition = "2018"

[dependencies]
hashbrown = "*"
dlmalloc = { version = "*", features = ["global"] }

src/main.rs

#![no_std]

#[panic_handler]
fn panic_handler(info: &core::panic::PanicInfo) -> ! {
    loop {}
}

#[global_allocator]
static GLOBAL_ALLOC: dlmalloc::GlobalDlmalloc = dlmalloc::GlobalDlmalloc;

#[no_mangle]
pub fn main() {
    let _book_reviews = hashbrown::HashMap::<(), ()>::new();
}

Command

RUSTFLAGS="-C target-feature=+soft-float,-sse,-sse2,-x87" cargo build  -Z build-std=core,alloc --target x86_64-unknown-linux-gnu

[phip1611]

Thanks for taking time on this @Amanieu. I agree that your solution solves the build problem for hashbrown. But now I have to go back to fontdue, which still causes the bug of Rustc/LLVM.

I created a minimal reproducible example on GitHub in case you are interested: https://github.com/phip1611/rust-llvm-bug-20220112-minimal-example

[Amanieu]

Possibly because the simd feature is enabled by default: https://github.com/mooman219/fontdue/blob/a7e02e9e4964e976520722dd2fdb7f8a6a41ad3b/Cargo.toml#L20

[phip1611]

By the way, there is a pitfall here that confused me at first. The newest fontdue version on GitHub made changes to the simd-feature that is not published on crates.io yet. Because the Cargo.toml on GitHub tells 0.6.2 I thought it is equal to the one on crates.io, which is not the case. The simd-feature flag changed since the release.

If I use fontdue without the simd feature in my GitHub repository linked above I get in fact an error from Rust with some useful information. Please look at heading Update #1 in https://github.com/phip1611/rust-llvm-bug-20220112-minimal-example/blob/main/README.md for the new error message.