* Illegal code generation: gcc-3.2 --target=m68k-elf
@ 2002-10-21 18:11 Peter Barada
2002-10-22 3:48 ` Richard Henderson
0 siblings, 1 reply; 10+ messages in thread
From: Peter Barada @ 2002-10-21 18:11 UTC (permalink / raw)
To: gcc; +Cc: Peter.Barada
I'm having trouble using gcc-3.2 to build a linux kernel. I've found
a case of illegal code geneation for gcc-3.2 with -m5200.
I'm in the midst of cutting the testcase down to a few lines, but the
crux of the problem is that I have a local variable that is a short
that is being incremented The variable itself has been pushed into
the stack, and since the ColdFire can't add shorts, the initial
RTL(from yy.c.00.rtl) looks like:
(note 688 687 689 ("yy.c") 3539)
(insn 689 688 690 (set (reg:SI 187)
(plus:SI (subreg:SI (reg/v:HI 40) 0)
(const_int 1 [0x1]))) -1 (nil)
(nil))
(insn 690 689 691 (set (reg/v:HI 40)
(subreg:HI (reg:SI 187) 2)) -1 (nil)
(nil))
Which is fine.
From yy.c.15.life:
(note 688 687 689 ("yy.c") 3539)
(insn 689 688 690 (set (reg:SI 187)
(plus:SI (subreg:SI (reg/v:HI 40) 0)
(const_int 1 [0x1]))) 99 {*addsi3_5200} (nil)
(expr_list:REG_DEAD (reg/v:HI 40)
(nil)))
(insn 690 689 691 (set (reg/v:HI 40)
(subreg:HI (reg:SI 187) 2)) 33 {*m68k.md:1024} (insn_list 689 (nil))
(expr_list:REG_DEAD (reg:SI 187)
(nil)))
So far the register death information looks correct. From yy.c.16.combine:
(note 688 687 689 ("yy.c") 3539)
(note 689 688 690 NOTE_INSN_DELETED)
(insn 690 689 691 (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))
Looks like combine put the two instructions together, but there is no
instruction in the ColdFire that can allow for this to happen (I guess
it found the pattern for addhi3 and assumed that it is valid for
ColdFire?). Somewhere its decided that (reg HI:40) won't live in a
register, so its put on the stack in slot -430, and the RTL is fixed
up to refer to it that way. the RTL stays the same until yy.c.21.greg:
(note 688 687 689 ("yy.c") 3539)
(note 689 688 1150 NOTE_INSN_DELETED)
(insn 1150 689 690 (set (reg:SI 0 %d0)
(const_int 1 [0x1])) 30 {*m68k.md:993} (nil)
(nil))
(insn 690 1150 691 (set (mem:SI (plus:SI (reg/f:SI 14 %a6)
(const_int -428 [0xfffffe54])) [0 rotate S4 A16])
(plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
(const_int -428 [0xfffffe54])) [0 rotate S4 A16])
(reg:SI 0 %d0))) 99 {*addsi3_5200} (nil)
(nil))
Now the RTL is bogus since the store to memory is *SImode* wide
whereas the original variable is HImode. From further inspection of
the assembler output of this function, I find the same results of
operations invoving AND and OR with this same variable.
As a test, I removed the addhi3 pattern, and the problem still persists.
Does anyone have any ideas why this is happening, and how I can
prevent it from happening?
As soon as I can cut the testcase down from a few thousand lines, I'll
submit it as a bug.
All ideas are appreciated.
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Illegal code generation: gcc-3.2 --target=m68k-elf
2002-10-21 18:11 Illegal code generation: gcc-3.2 --target=m68k-elf Peter Barada
@ 2002-10-22 3:48 ` Richard Henderson
2002-10-22 10:49 ` Peter Barada
0 siblings, 1 reply; 10+ messages in thread
From: Richard Henderson @ 2002-10-22 3:48 UTC (permalink / raw)
To: Peter Barada; +Cc: gcc, Peter.Barada
On Mon, Oct 21, 2002 at 07:22:24PM -0400, Peter Barada wrote:
> (insn 690 689 691 (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))
>
> Looks like combine put the two instructions together, but there is no
> instruction in the ColdFire that can allow for this to happen (I guess
> it found the pattern for addhi3 and assumed that it is valid for
> ColdFire?).
No. The constraints for addsi3_5200 say it's valid. And indeed
it would be if R40 were allocated to a register.
> (insn 690 1150 691 (set (mem:SI (plus:SI (reg/f:SI 14 %a6)
> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
> (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
> (reg:SI 0 %d0))) 99 {*addsi3_5200} (nil)
> (nil))
>
> Now the RTL is bogus since the store to memory is *SImode* wide
> whereas the original variable is HImode.
Are you _sure_ you're showing us everything? There should have
been some inefficient jiggery-pokery with subreg reloads. This
should not have been the real stack slot for R40, but somewhere
else.
r~
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Illegal code generation: gcc-3.2 --target=m68k-elf
2002-10-22 3:48 ` Richard Henderson
@ 2002-10-22 10:49 ` Peter Barada
2002-10-22 11:16 ` Richard Henderson
2002-10-22 21:00 ` Joel Sherrill
0 siblings, 2 replies; 10+ messages in thread
From: Peter Barada @ 2002-10-22 10:49 UTC (permalink / raw)
To: rth; +Cc: Peter.Barada, gcc, Peter.Barada
>> (insn 690 689 691 (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))
>>
>> Looks like combine put the two instructions together, but there is no
>> instruction in the ColdFire that can allow for this to happen (I guess
>> it found the pattern for addhi3 and assumed that it is valid for
>> ColdFire?).
>
>No. The constraints for addsi3_5200 say it's valid. And indeed
>it would be if R40 were allocated to a register.
Ok, so the add is valid, but this RTL has to be broken up into insns
later since the add can't deal with the subregs, right?
>> (insn 690 1150 691 (set (mem:SI (plus:SI (reg/f:SI 14 %a6)
>> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
>> (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
>> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
>> (reg:SI 0 %d0))) 99 {*addsi3_5200} (nil)
>> (nil))
>>
>> Now the RTL is bogus since the store to memory is *SImode* wide
>> whereas the original variable is HImode.
>
>Are you _sure_ you're showing us everything? There should have
>been some inefficient jiggery-pokery with subreg reloads. This
>should not have been the real stack slot for R40, but somewhere
>else.
I don't see *any* fiddling with subregs. I would have expected to see
a HImode load into a regieter, followed by the SImode add, followed by
an HImode store into the stack slot, but no. I thought I got
everything relavent. Here's *every* references to R40 from
yy.c.20.lreg:
(note 21 20 22 ("yy.c") 554)
(insn 22 21 23 (set (reg/v:HI 40)
(const_int 0 [0x0])) 33 {*m68k.md:1024} (nil)
(nil))
...
(note 522 521 523 ("yy.c") 622)
(insn 523 522 524 (set (reg/v:HI 40)
(const_int 0 [0x0])) 33 {*m68k.md:1024} (nil)
(nil))
...
(insn 677 676 678 (set (reg:SI 182)
(and:SI (subreg:SI (reg/v:HI 40) 0)
(const_int 3 [0x3]))) 177 {andsi3_5200} (nil)
(nil))
...
(note 688 687 689 ("yy.c") 640)
(note 689 688 690 NOTE_INSN_DELETED)
(insn 690 689 691 (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))
R40's name is 'rotate', and here's *every* referneces to 'rotate' or
R40 from yy.c.21.greg(including context):
Reloads for insn # 22
Reload 0: reload_out (HI) = (reg/v:HI 40)
DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg/v:HI 40)
reload_reg_rtx: (reg:HI 0 %d0)
...
Reloads for insn # 523
Reload 0: reload_out (HI) = (reg/v:HI 40)
DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg/v:HI 40)
reload_reg_rtx: (reg:HI 0 %d0)
...
Reloads for insn # 677
Reload 0: reload_in (SI) = (const_int 3 [0x3])
reload_out (SI) = (reg:SI 0 %d0 [182])
DATA_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (const_int 3 [0x3])
reload_out_reg: (reg:SI 0 %d0 [182])
reload_reg_rtx: (reg:SI 0 %d0 [182])
Reload 1: reload_in (HI) = (reg/v:HI 40)
DATA_REGS, RELOAD_FOR_INPUT (opnum = 2), optional
reload_in_reg: (reg/v:HI 40)
...
Reloads for insn # 690
Reload 0: reload_in (SI) = (const_int 1 [0x1])
DATA_REGS, RELOAD_FOR_INPUT (opnum = 2)
reload_in_reg: (const_int 1 [0x1])
reload_reg_rtx: (reg:SI 0 %d0)
...
(note 21 20 22 ("yy.c") 554)
(insn 22 21 1023 (set (reg:HI 0 %d0)
(const_int 0 [0x0])) 33 {*m68k.md:1024} (nil)
(nil))
(insn 1023 22 23 (set (mem:HI (plus:SI (reg/f:SI 14 %a6)
(const_int -428 [0xfffffe54])) [0 rotate S2 A16])
(reg:HI 0 %d0)) 33 {*m68k.md:1024} (nil)
(nil))
...
(note 522 521 523 ("yy.c") 622)
(insn 523 522 1114 (set (reg:HI 0 %d0)
(const_int 0 [0x0])) 33 {*m68k.md:1024} (nil)
(nil))
(insn 1114 523 524 (set (mem:HI (plus:SI (reg/f:SI 14 %a6)
(const_int -428 [0xfffffe54])) [0 rotate S2 A16])
(reg:HI 0 %d0)) 33 {*m68k.md:1024} (nil)
(nil))
...
(note 674 671 939 ("yy.c") 639)
;; Start of basic block 32, registers live: 10 [%a2] 14 [%a6] 15 [%sp] 33 34 35 37 38 39 40 41 43 46 62
(note 939 674 675 [bb 32] NOTE_INSN_BASIC_BLOCK)
(note 675 939 676 NOTE_INSN_DELETED)
(note 676 675 1142 NOTE_INSN_DELETED)
(insn 1142 676 677 (set (reg:SI 0 %d0 [182])
(const_int 3 [0x3])) 30 {*m68k.md:993} (nil)
(nil))
(insn 677 1142 678 (set (reg:SI 0 %d0 [182])
(and:SI (reg:SI 0 %d0 [182])
(mem:SI (plus:SI (reg/f:SI 14 %a6)
(const_int -428 [0xfffffe54])) [0 rotate S4 A16]))) 177 {andsi3_5200} (nil)
(nil))
(insn 678 677 679 (set (reg/f:SI 8 %a0 [183])
(plus:SI (reg/f:SI 14 %a6)
(reg:SI 0 %d0 [182]))) 99 {*addsi3_5200} (insn_list 677 (nil))
(nil))
...
(note 688 687 689 ("yy.c") 640)
(note 689 688 1150 NOTE_INSN_DELETED)
(insn 1150 689 690 (set (reg:SI 0 %d0)
(const_int 1 [0x1])) 30 {*m68k.md:993} (nil)
(nil))
(insn 690 1150 691 (set (mem:SI (plus:SI (reg/f:SI 14 %a6)
(const_int -428 [0xfffffe54])) [0 rotate S4 A16])
(plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
(const_int -428 [0xfffffe54])) [0 rotate S4 A16])
(reg:SI 0 %d0))) 99 {*addsi3_5200} (nil)
(nil))
Hopefully this is enough information. I'm still cutting the testcase
down to size... I hope to have a bug report soon.
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Illegal code generation: gcc-3.2 --target=m68k-elf
2002-10-22 10:49 ` Peter Barada
@ 2002-10-22 11:16 ` Richard Henderson
2002-10-22 11:18 ` Peter Barada
2002-10-22 14:20 ` Peter Barada
2002-10-22 21:00 ` Joel Sherrill
1 sibling, 2 replies; 10+ messages in thread
From: Richard Henderson @ 2002-10-22 11:16 UTC (permalink / raw)
To: Peter Barada; +Cc: Peter.Barada, gcc
On Tue, Oct 22, 2002 at 11:29:19AM -0400, Peter Barada wrote:
> Ok, so the add is valid, but this RTL has to be broken up into insns
> later since the add can't deal with the subregs, right?
Right.
> Hopefully this is enough information. I'm still cutting the testcase
> down to size... I hope to have a bug report soon.
This is going to have to be debugged. This should have been
handled by find_reloads_toplev, iirc.
r~
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Illegal code generation: gcc-3.2 --target=m68k-elf
2002-10-22 11:16 ` Richard Henderson
@ 2002-10-22 11:18 ` Peter Barada
2002-10-22 14:20 ` Peter Barada
1 sibling, 0 replies; 10+ messages in thread
From: Peter Barada @ 2002-10-22 11:18 UTC (permalink / raw)
To: rth; +Cc: Peter.Barada, Peter.Barada, gcc
>> Hopefully this is enough information. I'm still cutting the testcase
>> down to size... I hope to have a bug report soon.
>
>This is going to have to be debugged. This should have been
>handled by find_reloads_toplev, iirc.
I've cut the testcase down to only 139 lines from an original of 20125
lines... I'll submit it as a bug. What is interesting is the change
of the alias information(if I remember correctly) from [0 rotate S2
A16] in insn470 to [0 rotate S4 A16] in insn 270...
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Illegal code generation: gcc-3.2 --target=m68k-elf
2002-10-22 11:16 ` Richard Henderson
2002-10-22 11:18 ` Peter Barada
@ 2002-10-22 14:20 ` Peter Barada
1 sibling, 0 replies; 10+ messages in thread
From: Peter Barada @ 2002-10-22 14:20 UTC (permalink / raw)
To: rth; +Cc: Peter.Barada, gcc
>(note 688 687 689 ("yy.c") 640)
>
>(note 689 688 1150 NOTE_INSN_DELETED)
>
>(insn 1150 689 690 (set (reg:SI 0 %d0)
> (const_int 1 [0x1])) 30 {*m68k.md:993} (nil)
> (nil))
>
>(insn 690 1150 691 (set (mem:SI (plus:SI (reg/f:SI 14 %a6)
> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
> (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
> (reg:SI 0 %d0))) 99 {*addsi3_5200} (nil)
> (nil))
>
>> Hopefully this is enough information. I'm still cutting the testcase
>> down to size... I hope to have a bug report soon.
>
>This is going to have to be debugged. This should have been
>handled by find_reloads_toplev, iirc.
I've submitted this bug(with testcase) as target/8309. If there's
anything missing from the bug, please contact me...
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Illegal code generation: gcc-3.2 --target=m68k-elf
2002-10-22 10:49 ` Peter Barada
2002-10-22 11:16 ` Richard Henderson
@ 2002-10-22 21:00 ` Joel Sherrill
2002-10-23 18:19 ` Peter Barada
1 sibling, 1 reply; 10+ messages in thread
From: Joel Sherrill @ 2002-10-22 21:00 UTC (permalink / raw)
To: Peter Barada; +Cc: rth, Peter.Barada, gcc
This weekend, an RTEMS user reported a minor nit in
m68k/t-crtstuff which is causing bogus code on Coldfires.
It should be simple to fix and I think it rates being in the
upcoming release. I have filed PR8314 on it with a 1st
(broken) cut of a patch but I think this is more appropriate.
I am testing this patch now:
2002-10-22 Joel Sherrill <joel@OARcorp.com>
* config/m68k/t-crtstuff: Include crti.o, crtn.o, crtbegin.o
and crtend.o as multilib items.
diff -uNr
/usr1/rtems/work-tools/original/gcc-3.2/gcc/config/m68k/t-crtstuff
gcc-3.2/gcc/config/m68k/t-crtstuff
--- /usr1/rtems/work-tools/original/gcc-3.2/gcc/config/m68k/t-crtstuff
Tue Sep 14 04:52:09 1999
+++ gcc-3.2/gcc/config/m68k/t-crtstuff Tue Oct 22 17:47:14 2002
@@ -1,11 +1,10 @@
-# from ../t-svr4
-EXTRA_PARTS=crtbegin.o crtend.o crti.o crtn.o
+EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o crti.o crtn.o
# Add flags here as required.
CRTSTUFF_T_CFLAGS =
# Assemble startup files.
-crti.o: $(srcdir)/config/m68k/crti.s $(GCC_PASSES)
- $(GCC_FOR_TARGET) -c -o crti.o $(srcdir)/config/m68k/crti.s
-crtn.o: $(srcdir)/config/m68k/crtn.s $(GCC_PASSES)
- $(GCC_FOR_TARGET) -c -o crtn.o $(srcdir)/config/m68k/crtn.s
+$(T)crti.o: $(srcdir)/config/m68k/crti.s $(GCC_PASSES)
+ $(GCC_FOR_TARGET) -c -o $(T)crti.o $(srcdir)/config/m68k/crti.s
+$(T)crtn.o: $(srcdir)/config/m68k/crtn.s $(GCC_PASSES)
+ $(GCC_FOR_TARGET) -c -o $(T)crtn.o $(srcdir)/config/m68k/crtn.s
Peter Barada wrote:
>
> >> (insn 690 689 691 (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))
> >>
> >> Looks like combine put the two instructions together, but there is no
> >> instruction in the ColdFire that can allow for this to happen (I guess
> >> it found the pattern for addhi3 and assumed that it is valid for
> >> ColdFire?).
> >
> >No. The constraints for addsi3_5200 say it's valid. And indeed
> >it would be if R40 were allocated to a register.
>
> Ok, so the add is valid, but this RTL has to be broken up into insns
> later since the add can't deal with the subregs, right?
>
> >> (insn 690 1150 691 (set (mem:SI (plus:SI (reg/f:SI 14 %a6)
> >> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
> >> (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
> >> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
> >> (reg:SI 0 %d0))) 99 {*addsi3_5200} (nil)
> >> (nil))
> >>
> >> Now the RTL is bogus since the store to memory is *SImode* wide
> >> whereas the original variable is HImode.
> >
> >Are you _sure_ you're showing us everything? There should have
> >been some inefficient jiggery-pokery with subreg reloads. This
> >should not have been the real stack slot for R40, but somewhere
> >else.
>
> I don't see *any* fiddling with subregs. I would have expected to see
> a HImode load into a regieter, followed by the SImode add, followed by
> an HImode store into the stack slot, but no. I thought I got
> everything relavent. Here's *every* references to R40 from
> yy.c.20.lreg:
>
> (note 21 20 22 ("yy.c") 554)
>
> (insn 22 21 23 (set (reg/v:HI 40)
> (const_int 0 [0x0])) 33 {*m68k.md:1024} (nil)
> (nil))
>
> ...
>
> (note 522 521 523 ("yy.c") 622)
>
> (insn 523 522 524 (set (reg/v:HI 40)
> (const_int 0 [0x0])) 33 {*m68k.md:1024} (nil)
> (nil))
>
> ...
>
> (insn 677 676 678 (set (reg:SI 182)
> (and:SI (subreg:SI (reg/v:HI 40) 0)
> (const_int 3 [0x3]))) 177 {andsi3_5200} (nil)
> (nil))
>
> ...
>
> (note 688 687 689 ("yy.c") 640)
>
> (note 689 688 690 NOTE_INSN_DELETED)
>
> (insn 690 689 691 (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))
>
> R40's name is 'rotate', and here's *every* referneces to 'rotate' or
> R40 from yy.c.21.greg(including context):
>
> Reloads for insn # 22
> Reload 0: reload_out (HI) = (reg/v:HI 40)
> DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
> reload_out_reg: (reg/v:HI 40)
> reload_reg_rtx: (reg:HI 0 %d0)
>
> ...
>
> Reloads for insn # 523
> Reload 0: reload_out (HI) = (reg/v:HI 40)
> DATA_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
> reload_out_reg: (reg/v:HI 40)
> reload_reg_rtx: (reg:HI 0 %d0)
> ...
>
> Reloads for insn # 677
> Reload 0: reload_in (SI) = (const_int 3 [0x3])
> reload_out (SI) = (reg:SI 0 %d0 [182])
> DATA_REGS, RELOAD_OTHER (opnum = 0)
> reload_in_reg: (const_int 3 [0x3])
> reload_out_reg: (reg:SI 0 %d0 [182])
> reload_reg_rtx: (reg:SI 0 %d0 [182])
> Reload 1: reload_in (HI) = (reg/v:HI 40)
> DATA_REGS, RELOAD_FOR_INPUT (opnum = 2), optional
> reload_in_reg: (reg/v:HI 40)
>
> ...
>
> Reloads for insn # 690
> Reload 0: reload_in (SI) = (const_int 1 [0x1])
> DATA_REGS, RELOAD_FOR_INPUT (opnum = 2)
> reload_in_reg: (const_int 1 [0x1])
> reload_reg_rtx: (reg:SI 0 %d0)
>
> ...
>
> (note 21 20 22 ("yy.c") 554)
>
> (insn 22 21 1023 (set (reg:HI 0 %d0)
> (const_int 0 [0x0])) 33 {*m68k.md:1024} (nil)
> (nil))
>
> (insn 1023 22 23 (set (mem:HI (plus:SI (reg/f:SI 14 %a6)
> (const_int -428 [0xfffffe54])) [0 rotate S2 A16])
> (reg:HI 0 %d0)) 33 {*m68k.md:1024} (nil)
> (nil))
>
> ...
>
> (note 522 521 523 ("yy.c") 622)
>
> (insn 523 522 1114 (set (reg:HI 0 %d0)
> (const_int 0 [0x0])) 33 {*m68k.md:1024} (nil)
> (nil))
>
> (insn 1114 523 524 (set (mem:HI (plus:SI (reg/f:SI 14 %a6)
> (const_int -428 [0xfffffe54])) [0 rotate S2 A16])
> (reg:HI 0 %d0)) 33 {*m68k.md:1024} (nil)
> (nil))
>
> ...
>
> (note 674 671 939 ("yy.c") 639)
>
> ;; Start of basic block 32, registers live: 10 [%a2] 14 [%a6] 15 [%sp] 33 34 35 37 38 39 40 41 43 46 62
> (note 939 674 675 [bb 32] NOTE_INSN_BASIC_BLOCK)
>
> (note 675 939 676 NOTE_INSN_DELETED)
>
> (note 676 675 1142 NOTE_INSN_DELETED)
>
> (insn 1142 676 677 (set (reg:SI 0 %d0 [182])
> (const_int 3 [0x3])) 30 {*m68k.md:993} (nil)
> (nil))
>
> (insn 677 1142 678 (set (reg:SI 0 %d0 [182])
> (and:SI (reg:SI 0 %d0 [182])
> (mem:SI (plus:SI (reg/f:SI 14 %a6)
> (const_int -428 [0xfffffe54])) [0 rotate S4 A16]))) 177 {andsi3_5200} (nil)
> (nil))
>
> (insn 678 677 679 (set (reg/f:SI 8 %a0 [183])
> (plus:SI (reg/f:SI 14 %a6)
> (reg:SI 0 %d0 [182]))) 99 {*addsi3_5200} (insn_list 677 (nil))
> (nil))
>
> ...
>
> (note 688 687 689 ("yy.c") 640)
>
> (note 689 688 1150 NOTE_INSN_DELETED)
>
> (insn 1150 689 690 (set (reg:SI 0 %d0)
> (const_int 1 [0x1])) 30 {*m68k.md:993} (nil)
> (nil))
>
> (insn 690 1150 691 (set (mem:SI (plus:SI (reg/f:SI 14 %a6)
> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
> (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
> (const_int -428 [0xfffffe54])) [0 rotate S4 A16])
> (reg:SI 0 %d0))) 99 {*addsi3_5200} (nil)
> (nil))
>
> Hopefully this is enough information. I'm still cutting the testcase
> down to size... I hope to have a bug report soon.
>
> --
> Peter Barada Peter.Barada@motorola.com
> Wizard 781-852-2768 (direct)
> WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Illegal code generation: gcc-3.2 --target=m68k-elf
2002-10-22 21:00 ` Joel Sherrill
@ 2002-10-23 18:19 ` Peter Barada
2002-10-23 18:39 ` Joel Sherrill
0 siblings, 1 reply; 10+ messages in thread
From: Peter Barada @ 2002-10-23 18:19 UTC (permalink / raw)
To: joel.sherrill; +Cc: Peter.Barada, rth, Peter.Barada, gcc
>This weekend, an RTEMS user reported a minor nit in
>m68k/t-crtstuff which is causing bogus code on Coldfires.
>It should be simple to fix and I think it rates being in the
>upcoming release. I have filed PR8314 on it with a 1st
>(broken) cut of a patch but I think this is more appropriate.
Unfortunately this patch doesn't fix the problem that I'm seeing
(target/8309).
--
Peter Barada Peter.Barada@motorola.com
Wizard 781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Illegal code generation: gcc-3.2 --target=m68k-elf
2002-10-23 18:19 ` Peter Barada
@ 2002-10-23 18:39 ` Joel Sherrill
2002-10-23 21:23 ` Peter Barada
0 siblings, 1 reply; 10+ messages in thread
From: Joel Sherrill @ 2002-10-23 18:39 UTC (permalink / raw)
To: Peter Barada; +Cc: Peter.Barada, rth, gcc
Peter Barada wrote:
>
> >This weekend, an RTEMS user reported a minor nit in
> >m68k/t-crtstuff which is causing bogus code on Coldfires.
> >It should be simple to fix and I think it rates being in the
> >upcoming release. I have filed PR8314 on it with a 1st
> >(broken) cut of a patch but I think this is more appropriate.
>
> Unfortunately this patch doesn't fix the problem that I'm seeing
> (target/8309).
This looks like a different bug than the one I am trying to fix.
There was a mistake in the patch I posted. The correct version
is in my latest feedback to PR8314. I think this is a critical
patch for 3.2.1. It's correctness (finally) is easy to verify.
It installed multilib versions of the crt* code and the m5200
did not use a bsr instruction.
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?
> --
> Peter Barada Peter.Barada@motorola.com
> Wizard 781-852-2768 (direct)
> WaveMark Solutions(wholly owned by Motorola) 781-270-0193 (fax)
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Illegal code generation: gcc-3.2 --target=m68k-elf
2002-10-23 18:39 ` Joel Sherrill
@ 2002-10-23 21:23 ` Peter Barada
0 siblings, 0 replies; 10+ messages in thread
From: Peter Barada @ 2002-10-23 21:23 UTC (permalink / raw)
To: joel.sherrill; +Cc: Peter.Barada, rth, gcc
>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)
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-10-23 22:08 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-21 18:11 Illegal code generation: gcc-3.2 --target=m68k-elf Peter Barada
2002-10-22 3:48 ` Richard Henderson
2002-10-22 10:49 ` Peter Barada
2002-10-22 11:16 ` Richard Henderson
2002-10-22 11:18 ` Peter Barada
2002-10-22 14:20 ` Peter Barada
2002-10-22 21:00 ` Joel Sherrill
2002-10-23 18:19 ` Peter Barada
2002-10-23 18:39 ` Joel Sherrill
2002-10-23 21:23 ` Peter Barada
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).