Stream: git-wasmtime

Topic: wasmtime / issue #11234 Cranelift: `uadd_overflow_trap` c...


view this post on Zulip Wasmtime GitHub notifications bot (Jul 14 2025 at 08:31):

akldc opened issue #11234:

.clif Test Case

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


function %main() -> i64,i64,i64 fast {
    const0 = 0xced133c0b31e9648fbe1bba0869bb739

block0:

    v22 = iconst.i64 9223372036854775807   ; 2^63-1
    v24 = iconst.i64 0
    v30 = uadd_overflow_trap.i64 v22, v24, stk_ovf
    return v22,v24,v30
}

; print: %main()

Steps to Reproduce

Execute using run and interpret respectively.

$ clif-util run -v test1.clif
$ clif-util interpret -v test1.clif

Results

$ clif-util run -v test1.clif
%main() -> [9223372036854775807, 0, 9223372036854775807]
test1.clif
1 file
$ clif-util interpret -v test1.clif
%main() -> [9223372036854775807, 0, 9223372036854775807]
test1.clif
1 file

But when v24 is set to 1:

$ clif-util run -v test.clif
%main() -> [9223372036854775807, 1, -9223372036854775808]
test1.clif
1 file
$ clif-util interpret -v test1.clif
thread 'main' panicked at cranelift/interpreter/src/step.rs:287:55:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

9223372036854775807 (0x7fff ffff ffff ffff) is the maximum integer value of the i64 type, but adding 1 using the uadd instruction should not cause an overflow. Therefore, the result under the run command is as expected—0x8000000000000000, which is correctly interpreted as -9223372036854775808 in i64.
However, under the interpret command, it results in a crash.

Versions and Environment

Operating system: Ubuntu 22.04

Architecture: x86_64

view this post on Zulip Wasmtime GitHub notifications bot (Jul 14 2025 at 08:31):

akldc added the bug label to Issue #11234.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 14 2025 at 08:31):

akldc added the cranelift label to Issue #11234.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 14 2025 at 14:35):

alexcrichton added the cranelift:area:interpreter label to Issue #11234.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 16 2025 at 19:12):

alexcrichton closed issue #11234:

.clif Test Case

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


function %main() -> i64,i64,i64 fast {
    const0 = 0xced133c0b31e9648fbe1bba0869bb739

block0:

    v22 = iconst.i64 9223372036854775807   ; 2^63-1
    v24 = iconst.i64 0
    v30 = uadd_overflow_trap.i64 v22, v24, stk_ovf
    return v22,v24,v30
}

; print: %main()

Steps to Reproduce

Execute using run and interpret respectively.

$ clif-util run -v test1.clif
$ clif-util interpret -v test1.clif

Results

$ clif-util run -v test1.clif
%main() -> [9223372036854775807, 0, 9223372036854775807]
test1.clif
1 file
$ clif-util interpret -v test1.clif
%main() -> [9223372036854775807, 0, 9223372036854775807]
test1.clif
1 file

But when v24 is set to 1:

$ clif-util run -v test.clif
%main() -> [9223372036854775807, 1, -9223372036854775808]
test1.clif
1 file
$ clif-util interpret -v test1.clif
thread 'main' panicked at cranelift/interpreter/src/step.rs:287:55:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

9223372036854775807 (0x7fff ffff ffff ffff) is the maximum integer value of the i64 type, but adding 1 using the uadd instruction should not cause an overflow. Therefore, the result under the run command is as expected—0x8000000000000000, which is correctly interpreted as -9223372036854775808 in i64.
However, under the interpret command, it results in a crash.

Versions and Environment

Operating system: Ubuntu 22.04

Architecture: x86_64


Last updated: Dec 06 2025 at 07:03 UTC