Inconsistent results for Wasm `wide-arithmetic` proposal operation

[saulecabrera]

Describe the bug
Inconsistent results between Wasmi/Wasmtime for wide arithmetic operation.

Expected behavior
Same result between Wasmi/Wasmtime.

To Reproduce
Invoke the given Wasm program with 1 as a parameter.

Details

(module
  (type (;0;) (func (param i64) (result i32)))
  (table (;0;) 13 417 funcref)
  (global (;0;) i64 i64.const 4428280256543793216)
  (global (;1;) i64 i64.const 8079514241249670003)
  (global (;2;) (mut i32) i32.const 0)
  (global (;3;) (mut i64) i64.const 0)
  (global (;4;) (mut i32) i32.const 1000)
  (export "oj=pop 0(" (func 0))
  (export "" (table 0))
  (export "2" (global 0))
  (export "3" (global 1))
  (export "4" (global 2))
  (export ";\u{a}g\u{a}>]" (global 3))
  (elem (;0;) (i32.const 0) func)
  (elem (;1;) (i32.const 0) func 0 0)
  (elem (;2;) (i32.const 0) func 0)
  (elem (;3;) (i32.const 0) func 0)
  (elem (;4;) (i32.const 0) func)
  (elem (;5;) (i32.const 0) func)
  (func (;0;) (type 0) (param i64) (result i32)
    (local i32 i32 i64 i64 i64)
    global.get 4
    i32.eqz
    if ;; label = @1
      unreachable
    end
    global.get 4
    i32.const 1
    i32.sub
    global.set 4
    i32.const -32769
    i32.extend8_s
    i64.extend_i32_s
    i64.extend16_s
    i32.wrap_i64
    local.get 2
    i32.sub
    i64.extend_i32_s
    i32.const 2143289344
    i32.clz
    i32.popcnt
    i64.extend_i32_s
    i64.mul_wide_s
    i32.const 540491073
    local.set 1
    i64.ne
    local.set 1
    local.get 2
    i64.extend_i32_u
    i64.extend8_s
    i64.popcnt
    i64.extend16_s
    i64.extend16_s
    i64.extend16_s
    i64.extend16_s
    global.get 0
    i32.const -16385
    i32.extend8_s
    local.get 1
    i32.xor
    i64.extend_i32_s
    local.set 3
    i64.const 1
    local.get 3
    local.get 3
    i64.eqz
    select
    local.set 3
    local.set 4
    block ;; label = @1
      block ;; label = @2
        local.get 4
        local.get 3
        local.set 3
        local.tee 4
        i64.const -9223372036854775808
        i64.ne
        br_if 0 (;@2;)
        local.get 3
        i64.const -1
        i64.ne
        br_if 0 (;@2;)
        i64.const 1
        local.set 3
        br 1 (;@1;)
      end
    end
    local.get 4
    local.get 3
    i64.rem_s
    i32.const -16385
    i32.extend8_s
    local.get 1
    i32.xor
    i64.extend_i32_s
    i64.or
    local.set 5
    i64.const 1
    local.get 5
    local.get 5
    i64.eqz
    select
    i64.div_u
    i64.popcnt
    local.get 1
    i32.popcnt
    local.get 2
    local.get 0
    drop
    global.get 2
    i32.xor
    global.set 2
    global.get 2
    i32.xor
    global.set 2
    global.get 3
    i64.xor
    global.set 3
    global.get 2
  )
)

The result is 0 in Wasmtime, using both Cranelift/Winch. The result is 1 when using Wasmi.

1. What Wasmi version was used?

I used the latest main (commit 1a43c8e)

2. Ideally please provide minified Wasm (.wasm) or Wat (.wat) file to reproduce.

The attached program is the minimized test case from OSS-fuzz, I think it should be possible to minimize it a bit more, let me know if you'd like me to try and minimize it further.

[saulecabrera]

As an additional data point, if I remove the i64.mul_wide_s instruction from the attached program, the results are identical in Wasmi/Wasmtime.

[Robbepop]

Hi @saulecabrera, thanks a lot for the bug report. I will take a look into it as soon as I find time.

The wide_arithmetic proposal support was a more recent addition and has received very little feedback so far (partially because the associated proposal isn't even stable yet). Therefore, it isn't as battle tested as other proposal implementations and thus likely not very robust, yet.

Bug reports like these are very valueable!

[Robbepop]

@saulecabrera fixed in #1545.