shrink-wrap leads to ICE at dwarf2cfi.c

[Zhenqiang Chen]

Hi,

I am enabling shrink-wrap for ARM. But get lots of ICE during make
check for THUMB2:

internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2227.

Shrink-wrap allows jumps in epilogues. It will generate a common
simple_return block as the destination for multi-branches. More
details at http://old.nabble.com/Shrink-wrapping%3A-Introduction-to31220423.html

With this optimization, it might generate code segment like:
        ...
        bpl     .L9
        ...
        push    {r4}
        ...
        //NOTE_INSN_EPILOGUE_BEG
        ldr     r4, [sp], #4
.L9:
        bx      lr

In function maybe_record_trace_start, there is a check:

      /* We ought to have the same state incoming to a given trace no
         matter how we arrive at the trace.  Anything else means we've
         got some kind of optimization error.  */
      gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row));

The check will fail. Here are the results for cur_row and ti->beg_row

{cfa = {offset = 0, base_offset = 0, reg = 13, indirect = 0, in_use =
0}, cfa_cfi = 0x0, reg_save = 0x0}
{cfa = {offset = 4, base_offset = 0, reg = 13, indirect = 0, in_use =
0}, cfa_cfi = 0x0, reg_save = 0x7ffff726ab70}

The fix mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50833
is just to skip the optimization for -O0. It does not help on -O2/-O3.

All the cases pass if I disable the gcc_checking_assert.

1) Is the code segment the expected result of shrink-wrap? If not,
what's the correct one look like?

2) If the code is expected, does the gcc_checking_assert make sense?

Thanks!
-Zhenqiang