memory addressed by memory, error

memory addressed by memory, error

[Florent DEFAY]

Hi,

I am working on a new port for a 16 bit target.

In some tests from gcc.c-torture, there are internal errors due to
unrecognizable insn.
More precisely, it is about moving an operand which is memory
addressed by memory (impossible on the target).
_________________________________gcc/testsuite/gcc/gcc.log___(cuts)_______________________________
Executing on host: /home/guest1/gcc/build_target/gcc/xgcc
-B/home/guest1/gcc/build_target/gcc/   -O3 -fomit-frame-pointer
-funroll-loops  -w -fno-show-column -c  -o pr34458.o
/home/guest1/gcc/gcc-4.3.3/gcc/testsuite/gcc.c-torture/compile/pr34458.c
   (timeout = 300)
/home/guest1/gcc/gcc-4.3.3/gcc/testsuite/gcc.c-torture/compile/pr34458.c:
In function 'lint_operate':
/home/guest1/gcc/gcc-4.3.3/gcc/testsuite/gcc.c-torture/compile/pr34458.c:16:
error: unrecognizable insn:
(insn 467 277 278 6
/home/guest1/gcc/gcc-4.3.3/gcc/testsuite/gcc.c-torture/compile/pr34458.c:13
(set (reg:HI 0 r0 [101])
        (mem/s/c:HI (mem/c:HI (plus:HI (reg/f:HI 5 r5)
                    (const_int -2056 [0xfffff7f8])) [10 S2 A16]) [4
a.data S2 A16])) -1 (nil))
/home/guest1/gcc/gcc-4.3.3/gcc/testsuite/gcc.c-torture/compile/pr34458.c:16:
internal compiler error: in extract_insn, at recog.c:1990
____________________________________________________________________________________________

I faced this kind of problem earlier and I solved them by reviewing
GO_IF_LEGITIMATE_ADDRESS. Now I know
this part is rightly implemented. For the error above, I have the
proof that GO_IF_LEGITIMATE_ADDRESS rejects
the address (mem/c:HI (plus:HI (reg/f:HI 5 r5) (const_int -2056
[0xfffff7f8])) [10 S2 A16]), which is alright.

I tried to dump all and to look after the insn 467:

$ target-gcc -S pr34458.c -O3 -funroll-loops -da
pr34458.c: In function ‘lint_operate’:
pr34458.c:16: error: unrecognizable insn:
(insn 467 277 278 6 pr34458.c:13 (set (reg:HI 0 r0 [101])
        (mem/s/c:HI (mem/c:HI (plus:HI (reg/f:HI 5 r5)
                    (const_int -2056 [0xfffff7f8])) [10 S2 A16]) [4
a.data S2 A16])) -1 (nil))
pr34458.c:16: internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ grep 467 pr34458.c.*
$

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?
Thank you.

Regards.

Florent

Re: memory addressed by memory, error

[Ian Lance Taylor]

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

Re: memory addressed by memory, error

[Florent DEFAY]

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
>