wasm32-unknown-unknown produces "index out of bounds" when not optimized

[chrysn]

With the current nightly builds (1.24.0-nightly (73bca2b 2017-11-28)), some (I assume most) programs are unrunnable on wasm32-unknown-unknown (tested in Firefox 56.0) unless compiled with optimization flags. The condition appears somewhere between where the start function and main is called in this example, but I've also tested overriding the start function to a no-op, and then the most simple functions (just returning an integer) worked, but anything that called another function didn't.

Steps to reproduce:

#[no_mangle]
pub extern "C" fn pub_function(x: i32) -> i32 { 2 * x }
pub fn main() {}

as demo.rs; compile with rustc +nightly --target wasm32-unknown-unknown -O demo.rs and serve together with this index.html:

<script>
fetch("demo.wasm").then(response =>
    response.arrayBuffer()
).then(bytes =>
    WebAssembly.instantiate(bytes, {})
).then(results =>
    console.log(results.instance.exports.pub_function(42))
);
</script>

… and the console will print 84. Leave out the -O, and instead, the console will give RuntimeError: index out of bounds, with a stack trace 7 deep into the start function at a i32.store offset=4 instruction.

[alexcrichton]

Looks like this is a bug in LLVM -- if LLVM asserts are enabled I get:

rustc: /home/alex/code/rust2/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:8133: std::pair<llvm::SDValue, llvm::SDValue> llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&) const: Assertion `CLI.RetTy == Args[i].Ty && RetTys.size() == NumValues && "unexpected use of 'returned'"' failed.
zsh: abort (core dumped)  ./build/x86_64-unknown-linux-gnu/stage2/bin/rustc foo.rs --target   cdylib

and that was even with LLVM 5! We'll want to eventually report this upstream when we can get a reduced test case.

[jakerr]

Here's a reproduction: https://github.com/jakerr/wasm-bug-repro

[nathansobo]

Not sure if this is minimal enough to be helpful, but we're hitting this error when calling futures::sync::mpsc::unbounded. Here is a gist in case it's at all useful.

[alexcrichton]

Confirmed to be fixed with #48125!