bjorn3 edited issue #4234:
.clif
Test CaseNone reduced yet.
Steps to Reproduce
Try testing cg_clif with latest cranelift master.
Expected Results
CI passes
Actual Result
https://github.com/bjorn3/rustc_codegen_cranelift/actions/runs/2451819915
thread 'rustc' panicked at 'index out of bounds: the len is 96 but the index is 4294967295', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc2-0.2.2/src/ion/merge.rs:35:38
Versions and Environment
Cranelift version or commit: 3f152273
Operating system: Linux
Architecture: x86_64
cfallin commented on issue #4234:
Hmm, I will look at this ASAP, once there is a reduced testcase -- thanks!
bjorn3 commented on issue #4234:
Bugpoint produces a file with a different crash:
function u0:31() -> i32, i32 system_v { block0: v0 = iconst.i64 0 v1 = iconst.i32 0 v2 = iconst.i32 0 @0004 v28 = bconst.b1 false @0005 brnz v28, block25 jump block1 block1: @0005 trap unreachable block25: @0035 v85 = atomic_cas.i32 v0, v1, v2 @0036 trap user0 }
(cleaned up slightly by me)
This test case panics with:
thread 'main' panicked at 'index out of bounds: the len is 138 but the index is 2097151', /home/gh-bjorn3/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc2-0.2.2/src/ion/data_structures.rs:425:25 stack backtrace: [...] 5: <alloc::vec::Vec<T,A> as core::ops::index::IndexMut<I>>::index_mut at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/alloc/src/vec/mod.rs:2543:9 6: regalloc2::ion::data_structures::Env<F>::observe_vreg_class at /home/gh-bjorn3/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc2-0.2.2/src/ion/data_structures.rs:425:25 7: regalloc2::ion::liveranges::<impl regalloc2::ion::data_structures::Env<F>>::compute_liveness at /home/gh-bjorn3/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc2-0.2.2/src/ion/liveranges.rs:380:29 8: regalloc2::ion::<impl regalloc2::ion::data_structures::Env<F>>::init at /home/gh-bjorn3/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc2-0.2.2/src/ion/mod.rs:95:9 9: regalloc2::ion::run at /home/gh-bjorn3/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc2-0.2.2/src/ion/mod.rs:125:5 10: regalloc2::run at /home/gh-bjorn3/.cargo/registry/src/github.com-1ecc6299db9ec823/regalloc2-0.2.2/src/lib.rs:1380:5 11: cranelift_codegen::machinst::compile::compile at ./codegen/src/machinst/compile.rs:37:9 [...]
The test case reproducing the bug I originally reported is:
<details>
function u0:31(i64, i32, i32, i8, i8) -> i32, i32 system_v { ss0 = explicit_slot 16 ss1 = explicit_slot 16 ss2 = explicit_slot 16 ss3 = explicit_slot 16 ss4 = explicit_slot 16 ss5 = explicit_slot 16 ss6 = explicit_slot 48 ss7 = explicit_slot 48 ss8 = explicit_slot 48 gv0 = symbol colocated u1:29 gv1 = symbol colocated u1:30 gv2 = symbol colocated u1:31 gv3 = symbol colocated u1:32 gv4 = symbol colocated u1:33 gv5 = symbol colocated u1:34 gv6 = symbol colocated u1:35 gv7 = symbol colocated u1:36 gv8 = symbol colocated u1:37 sig0 = (i64 sret, i64, i64, i64, i64) system_v sig1 = (i64 sret, i64, i64, i64, i64) system_v sig2 = (i64, i64) system_v sig3 = (i64 sret, i64, i64, i64, i64) system_v sig4 = (i64, i64) system_v sig5 = (i64, i64) system_v fn0 = colocated u0:11 sig0 fn1 = colocated u0:11 sig1 fn2 = u0:110 sig2 fn3 = colocated u0:11 sig3 fn4 = u0:110 sig4 fn5 = u0:110 sig5 jt0 = jump_table [block2, block4, block5, block6, block7] block0(v0: i64, v1: i32, v2: i32, v3: i8, v4: i8): v34 -> v0 v40 -> v0 v46 -> v0 v52 -> v0 v58 -> v0 v64 -> v0 v70 -> v0 v76 -> v0 v82 -> v0 v35 -> v1 v41 -> v1 v47 -> v1 v53 -> v1 v59 -> v1 v65 -> v1 v71 -> v1 v77 -> v1 v83 -> v1 v36 -> v2 v42 -> v2 v48 -> v2 v54 -> v2 v60 -> v2 v66 -> v2 v72 -> v2 v78 -> v2 v84 -> v2 stack_store v3, ss1 stack_store v4, ss2 jump block1 block1: @0002 v5 = stack_load.i8 ss1 @0002 stack_store v5, ss4 @0003 v6 = stack_load.i8 ss2 @0003 stack_store v6, ss5 @0001 v7 = stack_load.i8 ss4 @0001 stack_store v7, ss3 @0001 v8 = stack_load.i8 ss5 @0001 stack_store v8, ss3+1 @0001 v9 = stack_load.i8 ss3 @0001 v10 = uextend.i64 v9 @0005 jump block37 block37: @0005 br_table.i64 v10, block36, jt0 block2: @0001 v11 = stack_load.i8 ss3+1 @0001 v12 = uextend.i64 v11 @0005 brz v12, block15 @0005 jump block3 block3: @0001 v13 = stack_load.i8 ss3+1 @0001 v14 = uextend.i64 v13 @0005 v15 = icmp_imm eq v14, 3 @0005 brnz v15, block27 @0005 jump block38 block38: @0005 v16 = icmp_imm.i64 eq v14, 1 @0005 brnz v16, block29 @0005 jump block8 block4: @0001 v17 = stack_load.i8 ss3+1 @0001 v18 = uextend.i64 v17 @0005 brz v18, block11 @0005 jump block3 block5: @0001 v19 = stack_load.i8 ss3+1 @0001 v20 = uextend.i64 v19 @0005 v21 = icmp_imm eq v20, 2 @0005 brnz v21, block9 @0005 jump block39 block39: @0005 brz.i64 v20, block19 @0005 jump block3 block6: @0001 v22 = stack_load.i8 ss3+1 @0001 v23 = uextend.i64 v22 @0005 v24 = icmp_imm eq v23, 2 @0005 brnz v24, block13 @0005 jump block40 block40: @0005 brz.i64 v23, block21 @0005 jump block3 block7: @0001 v25 = stack_load.i8 ss3+1 @0001 v26 = uextend.i64 v25 @0005 v27 = icmp_imm eq v26, 4 @0005 brnz v27, block17 @0005 jump block41 block41: @0005 v28 = icmp_imm.i64 eq v26, 2 @0005 brnz v28, block25 @0005 jump block42 block42: @0005 brz.i64 v26, block23 @0005 jump block3 block8: @0007 v29 = global_value.i64 gv0 @0007 v30 = iconst.i64 1 @0006 v31 = global_value.i64 gv1 @0006 v32 = iconst.i64 0 @0006 v33 = stack_addr.i64 ss8 @0006 call fn0(v33, v29, v30, v31, v32) @0006 jump block31 block9: @000d v37 = atomic_cas.i32 v34, v35, v36 @000d v38 = icmp eq v37, v35 @000d v39 = bint.i8 v38 @000d jump block10 block10: @000e jump block32(v37, v39) block11: @0012 v43 = atomic_cas.i32 v40, v41, v42 @0012 v44 = icmp eq v43, v41 @0012 v45 = bint.i8 v44 @0012 jump block12 block12: @0013 jump block32(v43, v45) block13: @0017 v49 = atomi [message truncated]
cfallin commented on issue #4234:
I've bisected this to 6df56e6aa60e20dbb21c7449a47fe711b668f82d (from #4223), the just-merged port of
atomic_cas
to ISLE. cc @abrownI'm looking into why now...
Last updated: Dec 23 2024 at 12:05 UTC