Re: memory addressed by memory, error

[Florent DEFAY <spira.inhabitant@gmail.com>]

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@google.com>:
> Florent DEFAY <spira.inhabitant@gmail.com> 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
>