Does this happen systematically with the compare insn or is it isolated?
I encountered this problem only once in gcc testsuite (gcc.c-torture/execute/builtins/strncat-chk.c).
I think the problem is quite rare because gcc does not put often a parallel compare insn into the delay slot of a conditional jump,
and when it happens it's not certain that the register clobbered by the parallel compare is used in the fall-through path after the conditional jump.
So I would say the problem is isolated.
This looks like a bug in the dbr pass (several of them have been fixed since
4.5.2) but it's impossible to be more precise without further details. The support of annulled instructions is not required for proper operation.
My current investigation showed that when I comment the call to 'fill_eager_delay_slots' in ' reorg.c:dbr_schedule' the problem disappear.
The problem does not come from the 2 others techniques for filling delay slots : 'fill_simple_delay_slots' or 'relax_delay_slots'.
To illustrate the problem previously described in asm, I copied and commented the rtl dumps below :