On 10/11/13 05:51, BELBACHIR Selim wrote:
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 :
I'd look at the code in resource.c very carefully, it's possible it's
not properly handling all the side effects of the parallel.
jeff
