Stream: git-wasmtime

Topic: wasmtime / issue #10976 Inconsistent result on riscv64 wi...


view this post on Zulip Wasmtime GitHub notifications bot (Jun 07 2025 at 13:18):

akldc opened issue #10976:

.clif Test Case

test optimize
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true


function %main() -> f64x2 fast {
    const0 = 0x66dcb93ce18195cd25ba9b1858b0b8d5

block0:
    v14 = vconst.f64x2 const0
    v16 = bor_not v14, v14  ; v14 = const0, v14 = const0
    v80 = fmul.f64x2 v14, v16  ; v14 = const0
    return v80
}

; print: %main()

Result

Run this test case on four architectures.

[x86    ] %main() -> 0xffffffffffffffffffffffffffffffff
[aarch64] %main() -> 0xffffffffffffffffffffffffffffffff
[riscv64] %main() -> 0x7ff80000000000007ff8000000000000
[s390x  ] %main() -> 0xffffffffffffffffffffffffffffffff

The result on riscv64 differs from the other architectures.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 07 2025 at 13:18):

akldc added the bug label to Issue #10976.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 07 2025 at 13:18):

akldc added the fuzz-bug label to Issue #10976.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 07 2025 at 15:54):

alexcrichton added the cranelift:area:riscv64 label to Issue #10976.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 13 2025 at 13:52):

akldc commented on issue #10976:

@alexcrichton Any follow‑up on this issue? I’ve found a few other related cases.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 13 2025 at 14:36):

alexcrichton commented on issue #10976:

Alas we don't have any one actively working on the riscv64 backend at this time. I took a glance and I don't immediately know the solution myself, but I'm also pretty unfamilar with riscv64's vector extension. I do think that these issues are valuable nevertheless, but if you've got some related issues it might make sense to drop more tests on the current issues instead of opening new issues?

If you're curious to continue to do this testing it may make sense to exclude riscv64 for now until these preexisting issues have been fixed too.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 15 2025 at 13:09):

akldc commented on issue #10976:

@alexcrichton
Ok, we won't be opening new issues for similar problems for now. We're very interested in Cranelift, and we might report new issues in the future if we run into something more meaningful or with different behavior — like issues related to other architectures such as aarch64 or s390x.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 15 2025 at 16:18):

alexcrichton closed issue #10976:

.clif Test Case

test optimize
    set opt_level=none
    set preserve_frame_pointers=true
    set enable_multi_ret_implicit_sret=true


function %main() -> f64x2 fast {
    const0 = 0x66dcb93ce18195cd25ba9b1858b0b8d5

block0:
    v14 = vconst.f64x2 const0
    v16 = bor_not v14, v14  ; v14 = const0, v14 = const0
    v80 = fmul.f64x2 v14, v16  ; v14 = const0
    return v80
}

; print: %main()

Result

Run this test case on four architectures.

[x86    ] %main() -> 0xffffffffffffffffffffffffffffffff
[aarch64] %main() -> 0xffffffffffffffffffffffffffffffff
[riscv64] %main() -> 0x7ff80000000000007ff8000000000000
[s390x  ] %main() -> 0xffffffffffffffffffffffffffffffff

The result on riscv64 differs from the other architectures.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 15 2025 at 16:18):

alexcrichton commented on issue #10976:

That seems reasonable yeah, I'm going to try again to poke at a few of these and see if I recognize them. FWIW if you're curious I'd be quite interested to hear more about what you're doing in in the Cranelift project meeting and I'm sure others would as well, so you're welcome to join if you'd like!


For this specific issue after digging in a bit I believe this is expected behavior. The results here are f64x2(NaN, NaN) and Cranelift doesn't guarantee deterministic NaN patterns across platforms. If I add set enable_nan_canonicalization=true I get the same result on riscv64 and x86 so this issue is otherwise working as intended. Now the others definitely look like legitimate issues though...

view this post on Zulip Wasmtime GitHub notifications bot (Jun 15 2025 at 19:00):

cfallin commented on issue #10976:

FWIW if you're curious I'd be quite interested to hear more about what you're doing in in the Cranelift project meeting and I'm sure others would as well, so you're welcome to join if you'd like!

I'll second this -- thanks for doing this round of fuzzing; and we're always interested in finding new ways of adding to our testing.


Last updated: Dec 06 2025 at 06:05 UTC