Stream: git-wasmtime

Topic: wasmtime / issue #13270 Cranelift: MachBuffer assertion w...


view this post on Zulip Wasmtime GitHub notifications bot (May 04 2026 at 22:05):

darioush opened issue #13270:

Hello! I found that a certain form of wasm with many chained i32.trunc_f64_s/ f64.convert_i32_s ops can trigger a panic during compilation on aarc64, but compiles fine on x86_64.

I can confirm the issue reproduces, and it is somewhat sad that I could not find a smaller reproduction. The specifics of the code involved here seems quite detailed and beyond my expertise. As such, I will include the LLM's analysis in case it is helpful:

.clif Test Case

One fcvt_to_sint.i32 f64 (which emits a Ldr19 constant-pool fixup on aarch64) followed by ~29,200 chained sdiv ops (which pile up deferred traps until the constant pool is forced past the 1 MB Ldr19 range):

function u0:0(f64, i32) -> i32 fast {
block0(v0: f64, v1: i32):
    v2 = fcvt_to_sint.i32 v0      ;; emits Ldr19 fixup at prologue offset ~20
    v3 = sdiv v2, v1               ;; }
    v4 = sdiv v3, v1               ;; } ~29,200 sdivs pile up deferred traps
    ;; ... 29,196 more sdivs ...   ;; }
    v29202 = sdiv v29201, v1
    return v29202
}

Generator (gen_clif.py N, default N=29200 panics reliably; threshold ~29,130):

import sys
N = int(sys.argv[1]) if len(sys.argv) > 1 else 29200
print('function u0:0(f64, i32) -> i32 fast {')
print('block0(v0: f64, v1: i32):')
print('    v2 = fcvt_to_sint.i32 v0')
prev = 'v2'
ssa = 3
for k in range(N):
    iv = ssa; ssa += 1
    print(f'    v{iv} = sdiv {prev}, v1')
    prev = f'v{iv}'
print(f'    return {prev}')
print('}')

Steps to Reproduce

gen_clif.py

gen.py

 python3 gen.py 16000 > repro.wat
wasm-tools parse repro.wat -o repro.wasm
wasmtime compile repro.wasm

Expected Results

Compiles successfully. (Verified: x86_64 with wasmtime compile repro.wasm exits 0 in 0.135s on a c2-standard-16 GCE instance with wasmtime 44.0.1.)

Actual Results

Release-mode panic on aarch64:

thread 'main' panicked at cranelift-codegen-0.131.1/src/machinst/buffer.rs:1496:17:
assertion failed: (label_offset - offset) <= kind.max_pos_range()
cranelift_codegen::machinst::buffer::MachBuffer<I>::handle_fixup
cranelift_codegen::machinst::buffer::MachBuffer<I>::emit_island_maybe_forced
cranelift_codegen::machinst::vcode::VCode<I>::emit
<cranelift_codegen::isa::aarch64::AArch64Backend as TargetIsa>::compile_function

Versions and Environment

Cranelift version: 0.131.0 and 0.131.1

wasmtime cranelift panic line
36.0.7 0.123.7 buffer.rs:1395
44.0.0 0.131.0 buffer.rs:1496
44.0.1 0.131.1 buffer.rs:1496

Operating system: macOS (Apple Silicon M-series).

Architecture: aarch64 panics; x86_64 unaffected.

Note on specificity. Only fcvt_to_sint.i32 f64 triggers; fcvt_to_uint, fcvt_to_sint.i64, and sdiv alone do not (the first two emit no Ldr19 on this backend, the last has no constant-pool load).

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2026 at 22:05):

darioush added the bug label to Issue #13270.

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2026 at 22:05):

darioush added the cranelift label to Issue #13270.

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2026 at 22:06):

cfallin closed issue #13270:

Hello! I found that a certain form of wasm with many chained i32.trunc_f64_s/ f64.convert_i32_s ops can trigger a panic during compilation on aarc64, but compiles fine on x86_64.

I can confirm the issue reproduces, and it is somewhat sad that I could not find a smaller reproduction. The specifics of the code involved here seems quite detailed and beyond my expertise. As such, I will include the LLM's analysis in case it is helpful:

.clif Test Case

One fcvt_to_sint.i32 f64 (which emits a Ldr19 constant-pool fixup on aarch64) followed by ~29,200 chained sdiv ops (which pile up deferred traps until the constant pool is forced past the 1 MB Ldr19 range):

function u0:0(f64, i32) -> i32 fast {
block0(v0: f64, v1: i32):
    v2 = fcvt_to_sint.i32 v0      ;; emits Ldr19 fixup at prologue offset ~20
    v3 = sdiv v2, v1               ;; }
    v4 = sdiv v3, v1               ;; } ~29,200 sdivs pile up deferred traps
    ;; ... 29,196 more sdivs ...   ;; }
    v29202 = sdiv v29201, v1
    return v29202
}

Generator (gen_clif.py N, default N=29200 panics reliably; threshold ~29,130):

import sys
N = int(sys.argv[1]) if len(sys.argv) > 1 else 29200
print('function u0:0(f64, i32) -> i32 fast {')
print('block0(v0: f64, v1: i32):')
print('    v2 = fcvt_to_sint.i32 v0')
prev = 'v2'
ssa = 3
for k in range(N):
    iv = ssa; ssa += 1
    print(f'    v{iv} = sdiv {prev}, v1')
    prev = f'v{iv}'
print(f'    return {prev}')
print('}')

Steps to Reproduce

gen_clif.py

gen.py

 python3 gen.py 16000 > repro.wat
wasm-tools parse repro.wat -o repro.wasm
wasmtime compile repro.wasm

Expected Results

Compiles successfully. (Verified: x86_64 with wasmtime compile repro.wasm exits 0 in 0.135s on a c2-standard-16 GCE instance with wasmtime 44.0.1.)

Actual Results

Release-mode panic on aarch64:

thread 'main' panicked at cranelift-codegen-0.131.1/src/machinst/buffer.rs:1496:17:
assertion failed: (label_offset - offset) <= kind.max_pos_range()
cranelift_codegen::machinst::buffer::MachBuffer<I>::handle_fixup
cranelift_codegen::machinst::buffer::MachBuffer<I>::emit_island_maybe_forced
cranelift_codegen::machinst::vcode::VCode<I>::emit
<cranelift_codegen::isa::aarch64::AArch64Backend as TargetIsa>::compile_function

Versions and Environment

Cranelift version: 0.131.0 and 0.131.1

wasmtime cranelift panic line
36.0.7 0.123.7 buffer.rs:1395
44.0.0 0.131.0 buffer.rs:1496
44.0.1 0.131.1 buffer.rs:1496

Operating system: macOS (Apple Silicon M-series).

Architecture: aarch64 panics; x86_64 unaffected.

Note on specificity. Only fcvt_to_sint.i32 f64 triggers; fcvt_to_uint, fcvt_to_sint.i64, and sdiv alone do not (the first two emit no Ldr19 on this backend, the last has no constant-pool load).

view this post on Zulip Wasmtime GitHub notifications bot (May 04 2026 at 22:06):

cfallin commented on issue #13270:

Hi -- this is a duplicate of #12968; we know about the issue and have a tentative plan to fix it (I just need to find the time). Thanks! I'll go ahead and close-as-duplicate.


Last updated: Jun 01 2026 at 09:49 UTC