alexcrichton opened issue #13229:
This input:
test interpret test run set opt_level=speed target x86_64 function %a(f64) { block0(v0: f64): v11 = band_not v0, v0 return }crashes with:
$ cargo run test ../out.clif Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s Running `/home/alex/code/wasmtime/target/debug/clif-util test ../out.clif` thread 'worker #0' (1457745) panicked at /home/alex/code/wasmtime/target/debug/build/cranelift-codegen-e399dfecead1442e/out/isle_opt.rs:25792:5: internal error: entered unreachable code: no rule matched for term iconst_u at src/prelude_opt.isle line 165; should it be partial? note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace [2026-04-29T13:14:38Z ERROR cranelift_filetests::concurrent] FAIL: panicked in worker #0: internal error: entered unreachable code: no rule matched for term iconst_u at src/prelude_opt.isle line 165; should it be partial? FAIL ../out.clif: panicked in worker #0: internal error: entered unreachable code: no rule matched for term iconst_u at src/prelude_opt.isle line 165; should it be partial? 1 tests Error: 1 failureI believe this is a regression from https://github.com/bytecodealliance/wasmtime/pull/13199 (cc @bongjunj)
alexcrichton added the fuzz-bug label to Issue #13229.
alexcrichton added the cranelift label to Issue #13229.
bongjunj commented on issue #13229:
Didn't expect float types can be matched to
bandop... Will look into this shortly
bongjunj commented on issue #13229:
I was inspired to write the PR because, in the change above,
eq,iadd,isuboperations are notty_int-constrained.
Why specificallybandis causing a bug, or just we didn't observe one ineq/iadd/isubcases?
Last updated: May 03 2026 at 22:13 UTC