Re: Illegal code generation: gcc-3.2 --target=m68k-elf

[Peter Barada <pbarada at mail dot wm dot sps dot mot dot com>]

>There is an RTEMS coldfire user trying to put together a cut down
>for the problem he describes as:
>
>> <ii> is a counter declared <short int> and used in a <for()> instruction.  gcc3.2 put it in frame position -10(a6).
>> As you can see in 1E85E it is treated as word but.... in in 1E8A0 it is used as long  : <add.l> !!!!
>> in 1E8A8 the test of end loop is made correctly as short! The result is that loop controlled by <ii> never finish!
>>  
>
>Does this look familiar by any chance?

In fact that sounds exactly like the bug I've tripped over(and
reported as (target/8309)...  The synopsis is that I have a word
length counter(called rotate) that is incremented by one in a loop.
Unfortunately the counter is not held in a register, but on the stack,
and instead of the expected:

    move.w -<rotate>(%a6),%d0
    addq.l #1,%d0
    move.w %d0,-<rotate>(%a6)

since ColdFire can't add words, gcc-3.2 generated:

    moveq.l #1,%d0
    add.l %d0,-<rotate>(%a6)

which increments the short *above* counter on the stack.  I'd be happy
to go chase it down, but I don't have a clue where to start looking in
the reload code for why it is blindly replacing:

(insn 293 292 294 (set (subreg:SI (reg/v:HI 40) 0)
        (plus:SI (subreg:SI (reg/v:HI 40) 0)
            (const_int 1 [0x1]))) 99 {*addsi3_5200} (nil)
    (nil))

with:

(insn 293 496 294 (set (mem:SI (plus:SI (reg/f:SI 14 %a6)
                (const_int -40 [0xffffffd8])) [24 rotate S4 A8])
        (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
                    (const_int -40 [0xffffffd8])) [24 rotate S4 A8])
            (reg:SI 1 %d1))) 99 {*addsi3_5200} (nil)
    (nil))

Any pointers to some documentation to shed some light on how reload
does its job would be *really* helpful.

>From a quick debug session, I think the culprit is causing
adjust_address_1 to be called:

adjust_address_1 (memref=0x4019a9c0, mode=SImode, offset=0, validate=1, 
    adjust=1)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/emit-rtl.c:1985
(gdb) call debug_rtx(memref)

(mem:HI (plus:SI (reg/f:SI 14 %a6)
        (const_int -40 [0xffffffd8])) [24 rotate S2 A8])


Which is forcing the subreg memory reference into an SImode
reference.  The callback at this point is:

(gdb) where 4
#0  adjust_address_1 (memref=0x4019a9c0, mode=SImode, offset=0, validate=1, 
    adjust=1)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/emit-rtl.c:1987
#1  0x080c9eb4 in alter_subreg (xp=0x401b4604)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/final.c:2741
#2  0x080c9dc3 in cleanup_subreg_operands (insn=0x401b39c0)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/final.c:2710
#3  0x0812c69d in reload (first=0x401ade00, global=1)
    at /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/reload1.c:1232

I don't have any idea where to look from here to figure it out.

Any ideas?

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)