Thank you Ian. I finally solved the problem by reviewing GO_IF_LEGITIMATE_ADDRESS again. I did not find explanation about this insn after the shorten pass. 2009/4/21 Ian Lance Taylor <iant@xxxxxxxxxx>: > Florent DEFAY <spira.inhabitant@xxxxxxxxx> writes: > >> So insn 467 appears in none dump file. >> I looked at 277 and 278 in dump files but it did not help at finding >> out the cause of this error. >> >> The last dump file where 277 and 278 appear is pr34458.c.205r.shorten: >> _______________________________pr34458.c.205r.shorten___(cuts)__________________ >> (insn 277 4 278 pr34458.c:9 (set (mem:HI (plus:HI (reg/f:HI 6 sp) >> (const_int -2 [0xfffffffe])) [0 S2 A16]) >> (reg/f:HI 5 r5)) -1 (nil)) >> >> (insn 278 277 279 pr34458.c:9 (set (reg/f:HI 5 r5) >> (reg/f:HI 6 sp)) -1 (nil)) >> ___________________________________________________________________________ >> >> Have you any idea about the cause of such an error? > > That seems very odd to me. I don't see what could introduce such an > insn after the shorten pass. I think your first step should be to fire > up the debugger and find out what is creating the insn. You can > probably do this with a conditional breakpoint on make_insn_raw when the > value of cur_insn_uid (a macro, so you need to look at the expanded > definition) == 467. > > Ian >
