http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50764
--- Comment #5 from vries at gcc dot gnu.org 2011-10-27 15:54:07 UTC ---
during 223r.dwarf2, maybe_record_trace_start is called with lab == code_label
29, at the start of block 5, and we hit the assert:
...
gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row));
...
The difference between cur_row and ti->beg_row can be seen here:
...
(gdb) p *cur_row
$4 = {cfa = {offset = 0, base_offset = 0, reg = 10, indirect = 0, in_use = 0},
cfa_cfi = 0x0, reg_save = 0x7ffff554a980}
(gdb) p *ti->beg_row
$6 = {cfa = {offset = 0, base_offset = -8, reg = 6, indirect = 1, in_use = 0},
cfa_cfi = 0x7ffff5696b70, reg_save = 0x7ffff554a850}
...
Apparently moving REG_CFA_DEF_CFA (reg:DI 39 r10) from block 4 to block 3
causes a different CFA state at the beginning of block 5, depending on whether
you arrive there from block 3 or block 2.
I don't know enough about dwarf to say whether the assert is ok or not, but it
seems to me that either the assert is wrong, or -fsched2-use-superblocks.
