f32::rem fails on wasm32-unknown-emscripten

[malbarbo]

This example (test for issue #27859):

#[inline(never)]
fn foo(a: f32, b: f32) -> f32 {
    a % b
}

#[inline(never)]
fn bar(a: f32, b: f32) -> f32 {
    ((a as f64) % (b as f64)) as f32
}

fn main() {
    let unknown_float = std::env::args().len();
    println!("{}", foo(4.0, unknown_float as f32));
    println!("{}", foo(5.0, (unknown_float as f32) + 1.0));
    println!("{}", bar(6.0, (unknown_float as f32) + 2.0));
    println!("{}", bar(7.0, (unknown_float as f32) + 3.0));
}

fails to compile for wasm32-unknown-emscripten with the error:

[wasm-validator error in function $__ZN1x3foo17h4d65114cf314b7c3E] 3 != 4: call param types must match, on
[f64] (call $f64-rem
 [f32] (get_local $4)
 [f32] (get_local $5)
)

[CryZe]

Looks like my code has also hit this bug: https://travis-ci.org/CryZe/livesplit-core/jobs/255487184#L401

Do we know where this bug is? If so, I probably want to try to fix it.

It seems like in my case I don't even have f64 at all, and yet it still uses f64-rem.

[pepyakin]

Minimized example:

define float @foo(float, float) unnamed_addr #2 {
start:
  %2 = frem float %0, %1
  ret float %2
}

emcc -s BINARYEN=1 -s "EXPORTED_FUNCTIONS=['_foo']" example.ll

Gives following output (stripped):

[wasm-validator error in function $_foo] 3 != 4: call param types must match[wasm-validator error in function $_foo] 3 != 4: call param types must match, on
[f64] (call $f64-rem
 [f32] (get_local $0)
 [f32] (get_local $1)
), on
[f64] (call $f64-rem
 [f32] (get_local $0)
 [f32] (get_local $1)
)
(on argument
(on argument 0)
0)
[wasm-validator error in function $_foo] [wasm-validator error in function $_foo] 3 != 4: 3 != 4: call param types must match, on
[f64call param types must match, on
[f64] (call $] (call $f64-rem
 [f64-rem
 [f32] (get_local f32] (get_local $0)
$0)
 [f32]  [f32] (get_local $1(get_local $1)
)
)
)
(on argument 1)

It seems like problem lies in Emscripten side of things.

[pepyakin]

Should be fixed by WebAssembly/binaryen#1106

[alexcrichton]

Looks like upstream fix (WebAssembly/binaryen#1106) is merged so closing, yay!