Closed T0b1-iOS closed 1 year ago
Thanks for the bug report! I don't know what the issue is, but I did find a simpler way to reproduce it:
RUST_LOG=trace cargo run -p cranelift-tools -- test cranelift/filetests/filetests/isa/x64/fp_sp_pc.clif
Another one that hits the same assert is cranelift/filetests/filetests/isa/x64/pinned-reg.clif
.
I think aside from those two, all the other x64 filetests pass. So the fact that these deal with special registers might be significant.
Maybe @elliottt or @cfallin can figure out what's going on here.
Hey everyone.
I noticed that when running the
component_model::strings::roundtrip
test like so (current main):the test fails due to a panic in the pretty printing of the MachInsts:
Last bit of the log output
``` 2023-05-02T23:13:42Z TRACE cranelift_codegen::machinst::lower] about to lower function: function u0:0(i64 vmctx, i64, i64, i64) system_v { sig0 = (i64 vmctx, i64, i32, i32, i32) fast fn0 = colocated u0:5 sig0 block0(v0: i64, v1: i64, v2: i64, v3: i64): v13 = iconst.i64 3 v4 = icmp uge v3, v13 ; v13 = 3 brif v4, block2, block1 block1 cold: trap user65535 block2: v5 = load.i32 notrap aligned little v2 v6 = load.i32 notrap aligned little v2+16 v7 = load.i32 notrap aligned little v2+32 v8 = load.i32 notrap aligned little v0 v14 = iconst.i32 0x6572_6f63 v9 = icmp eq v8, v14 ; v14 = 0x6572_6f63 brif v9, block4, block3 block3 cold: trap user65535 block4: v10 = load.i64 notrap aligned v0+8 v11 = get_stack_pointer.i64 store notrap aligned v11, v10+40 call fn0(v0, v1, v5, v6, v7) v16 = iconst.i8 1 brif v16, block6, block5 ; v16 = 1 block5 cold: trap user65535 block6: return } [2023-05-02T23:13:42Z TRACE cranelift_codegen::machinst::lower] lower_clif_block: block block6 inst inst14 (MultiAry { opcode: Return, args: EntityList { index: 0, unused: PhantomDataThe function in question is:
where the unwrap in the assert is where the panic comes from. It seems that there are no more allocations left? However, that is weird since it seems to be in the middle of the function as the inst before should be the
get_stack_pointer
instruction from block4.I'm not really familiar with how the pretty printing works in detail so maybe you have an idea why that's happening.