Stream: git-wasmtime

Topic: wasmtime / issue #12171 Cranelift: `band_not` triggers `a...

Wasmtime GitHub notifications bot (Dec 16 2025 at 13:52):

abc767234318 opened issue #12171:

.clif Test Case

test run

set enable_nan_canonicalization=true
set preserve_frame_pointers=true
set enable_multi_ret_implicit_sret=true
set opt_level=none

target x86_64 sse42 has_avx
target aarch64
target s390x
target riscv64gc has_zcd has_zbkb has_zbc has_zbs has_zicond has_zvl32b has_zvl64b has_zvl128b has_zvl1024b has_zvl2048b has_zvl4096b has_zvl8192b has_zvl16384b has_zvl32768b
function %main() -> f64 fast {

block0:
    v2 = f64const 0.0
    v5 = iconst.i32 -428912370
    v11 = f64const 0x1.fffffffffffffp1023
    v22 = iconst.i32 0
    v39 = band_not v11, v2  ; v11 = 0x1.fffffffffffffp1023, v2 = 0.0
    return v39
}


; print: %main()

Steps to Reproduce

I ran this test case using the following command and it crashed on the aarch64 platform. However, this phenomenon did not appear on other platforms such as x86_64 and riscv64.

qemu-aarch64 -L /usr/aarch64-linux-gnu clif-util run -v ./test.clif

Expected Results

%main() -> 0x1.fffffffffffffp1023

Actual Results

thread 'main' panicked at cranelift/codegen/src/isa/aarch64/inst/emit.rs:97:5:
assertion `left == right` failed
  left: Float
 right: Int

Wasmtime GitHub notifications bot (Dec 16 2025 at 13:52):

abc767234318 added the bug label to Issue #12171.

Wasmtime GitHub notifications bot (Dec 16 2025 at 13:52):

abc767234318 added the cranelift label to Issue #12171.

Wasmtime GitHub notifications bot (Dec 17 2025 at 00:00):

cfallin commented on issue #12171:

@abc767234318 regarding this and your other two recent issues (#12170, #12165): thank you for fuzzing our compiler. It might be good for you to read our fuzzing guidelines if you haven't already. And in general, it would be good to be mindful of the compiler's guarantees and our state as a project: we guarantee and ensure the core of Cranelift used by Wasmtime is robust, but other instructions are implemented more or less on a best-effort basis, and we don't have a lot of spare labor to fill in the gaps right now. You'll probably find more instructions that aren't implemented on one or more backends. It isn't that helpful to get one-off bugs for these. Or stated more simply: it is not an efficient use of our time to take many small interrupts to stochastically fill in small bits of the missing gap, when we know the gap exists.

What would be more helpful for our project is some sort of table or checklist of all instructions that are not implemented for each backend. That could then allow for someone willing to do a little work to help with one or two new lowerings. It would be great to have an organized "completeness" effort of this kind. Would you be willing to do a systematic survey or test and build such a table?

Wasmtime GitHub notifications bot (Dec 17 2025 at 02:19):

abc767234318 commented on issue #12171:

@abc767234318 regarding this and your other two recent issues (#12170, #12165): thank you for fuzzing our compiler. It might be good for you to read our fuzzing guidelines if you haven't already. And in general, it would be good to be mindful of the compiler's guarantees and our state as a project: we guarantee and ensure the core of Cranelift used by Wasmtime is robust, but other instructions are implemented more or less on a best-effort basis, and we don't have a lot of spare labor to fill in the gaps right now. You'll probably find more instructions that aren't implemented on one or more backends. It isn't _that_ helpful to get one-off bugs for these. Or stated more simply: it is not an efficient use of our time to take many small interrupts to stochastically fill in small bits of the missing gap, when we know the gap exists.

What would be more helpful for our project is some sort of table or checklist of all instructions that are not implemented for each backend. That could then allow for someone willing to do a little work to help with one or two new lowerings. It would be great to have an organized "completeness" effort of this kind. Would you be willing to do a systematic survey or test and build such a table?

That is a great idea. I am happy to provide the systematic table/checklist of unimplemented instructions. I already have several 'not implemented' cases ready, and I'd be delighted to contribute to Cranelift in this organized way.

I can also provide a minimal test case for each discovery.

How would you prefer I submit this? A single GitHub Issue, or a different method?

Wasmtime GitHub notifications bot (Dec 17 2025 at 02:27):

cfallin commented on issue #12171:

A single GitHub issue is great; some sort of table or checklist, organized by backend and then maybe by (say) operand type would be perfect. Thanks! (And if you aren't confident it's complete, we can always edit the post.)

In GitHub Markdown syntax, [ ] creates an empty checkbox and anyone with edit permission can click it to check the box (which becomes [x]).

Wasmtime GitHub notifications bot (Dec 17 2025 at 02:34):

abc767234318 commented on issue #12171:

I will post it soon. Thanks again for the guidance!

Wasmtime GitHub notifications bot (Dec 22 2025 at 07:05):

abc767234318 closed issue #12171:

.clif Test Case

test run

set enable_nan_canonicalization=true
set preserve_frame_pointers=true
set enable_multi_ret_implicit_sret=true
set opt_level=none

target x86_64 sse42 has_avx
target aarch64
target s390x
target riscv64gc has_zcd has_zbkb has_zbc has_zbs has_zicond has_zvl32b has_zvl64b has_zvl128b has_zvl1024b has_zvl2048b has_zvl4096b has_zvl8192b has_zvl16384b has_zvl32768b
function %main() -> f64 fast {

block0:
    v2 = f64const 0.0
    v5 = iconst.i32 -428912370
    v11 = f64const 0x1.fffffffffffffp1023
    v22 = iconst.i32 0
    v39 = band_not v11, v2  ; v11 = 0x1.fffffffffffffp1023, v2 = 0.0
    return v39
}


; print: %main()

Steps to Reproduce

I ran this test case using the following command and it crashed on the aarch64 platform. However, this phenomenon did not appear on other platforms such as x86_64 and riscv64.

qemu-aarch64 -L /usr/aarch64-linux-gnu clif-util run -v ./test.clif

Expected Results

%main() -> 0x1.fffffffffffffp1023

Actual Results

thread 'main' panicked at cranelift/codegen/src/isa/aarch64/inst/emit.rs:97:5:
assertion `left == right` failed
  left: Float
 right: Int

Wasmtime GitHub notifications bot (Dec 22 2025 at 07:05):

abc767234318 commented on issue #12171:

As suggested, I've moved this case to the new tracking list here: #12197 . I'll close this one now

Last updated: Jan 09 2026 at 13:15 UTC