[Bug rtl-optimization/51271] ICE in in maybe_record_trace_start, at dwarf2cfi.c:2244
vries at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Nov 23 14:12:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51271
--- Comment #7 from vries at gcc dot gnu.org 2011-11-23 13:35:13 UTC ---
triggering assert: gcc_checking_assert (cfi_row_equal_p (cur_row,
ti->beg_row));
relevant values:
...
(gdb) call debug_cfi_row (cur_row)
.cfi_def_cfa 29, 16
(gdb) call debug_cfi_row (ti->beg_row)
.cfi_def_cfa 29, 16
.cfi_offset 28, -8
...
The cur_row is the state belonging to the current transition, which is
'saw edge from trace 2 to 3 (via fallthru 0)'
meaning the fallthru from bb 7 to bb 8.
The ti->beg_row is the state at the start of trace 3, which was generated by
'saw edge from trace 1 to 3 (via jump_insn 156)'
meaning the jump from block 5 to block 8.
So we've got:
...
block 7 -> block 8
.cfi_def_cfa 29, 16
block 5 -> block 8
.cfi_def_cfa 29, 16
.cfi_offset 28, -8
...
This difference seems related to epilogue insn 141:
...
(insn 141 155 142 (set (reg:DI 28 $28)
(mem/c:DI (plus:SI (reg/f:SI 29 $sp)
(const_int 8 [0x8])) [4 S8 A64])) res_hconf.c:11 278
{*movdi_64bit}
(nil))
...
Insn 141 is copied by pass_mach (probably by dbr_schedule) to:
- the delay slot of jump_insn 63 in bb 4, and to
- the delay slot of jump_insn 75 in bb 6.
jump_insn 63 is an annuling jump (jump_insn/u) and insn 141 is only executed
then the branch is taken (insn/s), so it does not disturb the fallthru path.
...
(insn 177 62 65 (sequence [
(jump_insn/u 63 62 141 (set (pc)
(if_then_else (eq (reg:SI 4 $4 [orig:242 D.2240 ] [242])
(reg:SI 3 $3 [256]))
(label_ref:SI 176)
(pc))) res_hconf.c:8 434 {*branch_equalitysi}
(expr_list:REG_BR_PRED (const_int 48 [0x30])
(expr_list:REG_DEAD (reg:SI 4 $4 [orig:242 D.2240 ] [242])
(expr_list:REG_DEAD (reg:SI 3 $3 [256])
(expr_list:REG_EQUAL (if_then_else (eq (reg:SI 4 $4
[orig:242 D.2240 ] [242])
(const_int 44 [0x2c]))
(label_ref:SI 176)
(pc))
(expr_list:REG_BR_PROB (const_int 300 [0x12c])
(nil))))))
-> 176)
(insn/s 141 63 65 (set (reg:DI 28 $28)
(mem/c:DI (plus:SI (reg/f:SI 29 $sp)
(const_int 8 [0x8])) [4 S8 A64])) 278
{*movdi_64bit}
(nil))
]) res_hconf.c:8 -1
(nil))
...
jump_insn 75 is an normal jump and insn 141 is executed on either branch or
fallthru path.
...
(insn 178 74 76 (sequence [
(jump_insn 75 74 141 (set (pc)
(if_then_else (eq (reg:SI 4 $4 [orig:259 *D.2245_8 ] [259])
(const_int 0 [0]))
(label_ref:SI 176)
(pc))) res_hconf.c:7 434 {*branch_equalitysi}
(expr_list:REG_BR_PRED (const_int 48 [0x30])
(expr_list:REG_DEAD (reg:SI 4 $4 [orig:259 *D.2245_8 ]
[259])
(expr_list:REG_BR_PROB (const_int 300 [0x12c])
(nil))))
-> 176)
(insn 141 75 76 (set (reg:DI 28 $28)
(mem/c:DI (plus:SI (reg/f:SI 29 $sp)
(const_int 8 [0x8])) [4 S8 A64])) 278
{*movdi_64bit}
(nil))
]) res_hconf.c:7 -1
(nil))
...
The execution of insn 141 in bb 6 on the fallthru path causes the difference in
cfa state at the entry of bb8, which causes the assert.
Disregarding cfa info, the branch delay scheduling looks correct to me.
I guess we need analyze why the epilogue insn is not handled more conservative
by branch delay scheduling, and fix that.
More information about the Gcc-bugs
mailing list