Thanks for the hints ! I found a recent correction on resource.c ' https://github.com/mirrors/gcc/commit/d8e17376c1b6ba379cc918f06843792e35c4e38e' which treat my problem. It seems my problem was not related to my parallel compare insn but produced by the conditional call at the beginning of the target path. Let's hope this correction does not hide another problem by just applying a side effect on my specific test case :) Regards,
Selim -----Message d'origine----- De : Jeff Law [mailto:l...@redhat.com] Envoyé : vendredi 11 octobre 2013 22:34 À : BELBACHIR Selim; Eric Botcazou Cc : gcc@gcc.gnu.org Objet : Re: delay slot of conditionnal branch with no annuled jump strategy 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
