This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: memory addressed by memory, error


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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]