Stream: git-wasmtime

Topic: wasmtime / issue #10951 Cranelift: Function call causes u...

Wasmtime GitHub notifications bot (Jun 06 2025 at 13:42):

akldc opened issue #10951:

.clif Test Case

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

function u1:1(i64) -> i64 fast {
    ss0 = explicit_slot 32
    ss1 = explicit_slot 32
    const0 = 0xbdea39e5631c0104d92f26de921e6dbf

block0(v2: i64):
    v1 = iconst.i64 -5608073308517523622
    v3 = vconst.f32x4 const0
    stack_store v1, ss0
    stack_store v1, ss0+8
    stack_store v1, ss0+16
    stack_store v1, ss0+24
    stack_store v3, ss1
    stack_store v3, ss1+16
    return v2
}

function %main() -> i16x8, f64x2 fast {
    sig0 = (i64) -> i64 fast
    fn0 = u1:1 sig0
    const0 = 0x00110022003300440055006600770088

block0:
    v1 = iconst.i64 0x1f96_3ea8_4eb6_5f81
    v11 = vconst.i16x8 const0
    v13 = vconst.f32x4 const0
    v26 = fvpromote_low v13
    v45 = call fn0(v1)
    return  v11, v26
}

; print: %main()

Result

Run this test case on four architectures.

[x86    ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[aarch64] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[riscv64] %main() -> [0x000000000000002e0000555500770088, 0x00005555568fb3100000000000000000]
[s390x  ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]

If you remove the instruction v45 = call fn0(v1) and re-run the case, it works as expected.

[x86    ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[aarch64] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[riscv64] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[s390x  ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]

So, on the riscv64 architecture, calling the function u1:1 changes the values of v11 and v26.

Wasmtime GitHub notifications bot (Jun 06 2025 at 13:42):

akldc added the bug label to Issue #10951.

Wasmtime GitHub notifications bot (Jun 06 2025 at 13:42):

akldc added the cranelift label to Issue #10951.

Wasmtime GitHub notifications bot (Jun 06 2025 at 14:48):

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

Wasmtime GitHub notifications bot (Jun 12 2025 at 17:59):

alexcrichton commented on issue #10951:

cc https://github.com/bytecodealliance/wasmtime/pull/11026 which has a test that I ignored on riscv64 and may be related to this issue (unsure though)

Wasmtime GitHub notifications bot (Jun 13 2025 at 14:57):

akldc commented on issue #10951:

@alexcrichton It seems that the bug in #11024 has been fixed, but this issue still remains.

Wasmtime GitHub notifications bot (Jun 13 2025 at 15:00):

alexcrichton commented on issue #10951:

Oh that's expected yeah, the test I added in that PR failed on riscv64 so I had to ignore it on riscv64, and my suspicion is that it was related to one of the issues you opened. (the bugfix was only for x86)

Wasmtime GitHub notifications bot (Jun 15 2025 at 16:41):

alexcrichton commented on issue #10951:

Ah this one turned out to be a relatively easy fix!

Wasmtime GitHub notifications bot (Jun 15 2025 at 19:20):

cfallin closed issue #10951:

.clif Test Case

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

function u1:1(i64) -> i64 fast {
    ss0 = explicit_slot 32
    ss1 = explicit_slot 32
    const0 = 0xbdea39e5631c0104d92f26de921e6dbf

block0(v2: i64):
    v1 = iconst.i64 -5608073308517523622
    v3 = vconst.f32x4 const0
    stack_store v1, ss0
    stack_store v1, ss0+8
    stack_store v1, ss0+16
    stack_store v1, ss0+24
    stack_store v3, ss1
    stack_store v3, ss1+16
    return v2
}

function %main() -> i16x8, f64x2 fast {
    sig0 = (i64) -> i64 fast
    fn0 = u1:1 sig0
    const0 = 0x00110022003300440055006600770088

block0:
    v1 = iconst.i64 0x1f96_3ea8_4eb6_5f81
    v11 = vconst.i16x8 const0
    v13 = vconst.f32x4 const0
    v26 = fvpromote_low v13
    v45 = call fn0(v1)
    return  v11, v26
}

; print: %main()

Result

Run this test case on four architectures.

[x86    ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[aarch64] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[riscv64] %main() -> [0x000000000000002e0000555500770088, 0x00005555568fb3100000000000000000]
[s390x  ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]

If you remove the instruction v45 = call fn0(v1) and re-run the case, it works as expected.

[x86    ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[aarch64] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[riscv64] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]
[s390x  ] %main() -> [0x00110022003300440055006600770088, 0x3805401980000000380dc02200000000]

So, on the riscv64 architecture, calling the function u1:1 changes the values of v11 and v26.

Last updated: Dec 06 2025 at 07:03 UTC