Cranelift: `uadd_overflow_trap` causes crash in `interpret` but succeeds in `run` for i64::MAX + 1

[akldc]

.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