Doesn't compile with "+soft-float": Compiler LLVM Error: "Do not know how to split the result of this operator"

[phip1611]

This is probably a bug in the Rust compiler but maybe this can be easily fixed by a workaround or someone already has experience with this error?

When this crate gets compiled with cargo rustc -- -C target-feature=+soft-float cargo exits with an error and LLVM says: "Do not know how to split the result of this operator"

I already checked the dependencies ttf-parser and hashbrown, but the problem occurs only in fontdue with different Rust compiler versions accross stable and nightly releases. Anyone has an idea?

[phip1611]

Related issue from 2019: rust-lang/rust#61721

[phip1611]

Disabling the simd-feature doesn't change anything, unfortunately.

[mooman219]

Do you have a stack trace or anything that narrows down the investigation?

[phip1611]

In the meantime, I found out that the problem originates in hashbrown-dependency.

Not when building the library but when building an executable, that uses it. Minimal example:

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

Compiled with $ cargo rustc --bin bug -- -C target-feature=+soft-float,-sse,-sse2,-x87

Update 1
In the meantime, the maintainer of hashbrown helped to fix at least the build of hashbrown: rust-lang/hashbrown#306 (comment)

Unfortunately, I still can verify that its fontdue that causes Rustc/LLVM errors. I created a minimal reproducible example: https://github.com/phip1611/rust-llvm-bug-20220112-minimal-example

Update 2
I use the version from GitHub as dependency (newer than on crates.io!) and disabled the simd-feature. Now I ran into rust-lang/rust#62729 - there is a work-around shown that executables can include. This is really unfortunate and I hope that the Rust maintainers can find a better solution to cope with such situations.

[mooman219]

I'm going to tentatively mark this as wontfix since it's not clear to me that the actual issue is in fontdue, but leave this bug open for now because this isn't the first time fontdue exposed a bug in llvm.

[Hugo4IT]

Is there a workaround for this? Or will I just have to sit and wait for LLVM to fix this...

[phip1611]

@Hugo4IT the workaround is to either use the crate without the simd-feature and soft-float or to pre-render all characters, such as https://crates.io/crates/noto-sans-mono-bitmap does it

[Hugo4IT]

Using the crate without the SIMD feature still brought up some linker errors, but those were solvable by simply copying the fminf and fmaxf functions from the libm source code, and adding them to my code with #[no_mangle], I guess Rust couldn't find them.

[mooman219]

Using the crate without the SIMD feature still brought up some linker errors, but those were solvable by simply copying the fminf and fmaxf functions from the libm source code, and adding them to my code with #[no_mangle], I guess Rust couldn't find them.

@Hugo4IT seems strange, I don't use min/max in fontdue. Disabling simd should be sufficient. What does your environment look like?

[phip1611]

@Hugo4IT @mooman219 this is a bug by Rust when using the "+soft-float" feature on x86.

more info: rust-lang/rust#62729