[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