SIGSEGV when compiling for target wasm32-unknown-unknown with LLVM target feature 'multivalue'

[adrian17]

I tried this code:

pub fn f() -> ! {
    panic!("");
}

With compiler invocation: rustc --crate-type lib mytest.rs --target wasm32-unknown-unknown -C target-feature=+multivalue

I expected to see this happen: no failure

Instead, this happened:

Segmentation fault (core dumped)

Meta

rustc --version --verbose:

rustc 1.46.0-nightly (16957bd4d 2020-06-30)
binary: rustc
commit-hash: 16957bd4d3a5377263f76ed74c572aad8e4b7e59
commit-date: 2020-06-30
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly
LLVM version: 10.0

Backtrace

No backtrace.

Can also be reproduced on godbolt with current nightly: https://godbolt.org/z/Pqg986
Also, there is no crash when the feature is not enabled (not mentioned at all or -C target-feature=-multivalue), or when I build with -O.

[adrian17]

(Probably A-LLVM?)

[CryZe]

It seems like using u128 / i128 segfaults multivalue as well on beta and nightly. It works on 1.44.
https://rust.godbolt.org/z/AXRnar

This seems like a regression in LLVM 10.

[adrian17]

This seems like a regression in LLVM 10.

I think the feature wasn't actually implemented prior to LLVM 10.

[CryZe]

Ah yeah seems like it

[alexcrichton]

I tested this on LLVM trunk and wasn't able to reproduce the same crash, so this will likely get fixed when we update LLVM.

[adrian17]

With recent LLVM upgrade this particular crash disappears, but in general it still segfaults when compiling a nontrivial crate, like svg.

New example:

// --target wasm32-unknown-unknown -C target-feature=+multivalue -O

pub fn read_number(number: &str) -> Result<f32, std::num::ParseFloatError> {
    number.parse()
}

Godbolt: https://godbolt.org/z/TTffx3

[adrian17]

For the record, the example above is still reproducible after LLVM 12 upgrade.

[adrian17]

I made a more low-level reproduction of the example above:

https://github.com/adrian17/multivalue-crash-repro/

(unfortunately I couldn't put it on godbolt, as without the crate boundary it compiled correctly)

I'm guessing it's originating from compiling this line:

f32::from_bits(bits.try_into().unwrap_or_else(|_| unreachable!()))

And remaining code is there just to defeat optimizations that would un-break later passes.

[daxpedda]

I just confirmed that this has been working since v1.62.