Subject: re: EGCS on mips stable?
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Castor Fu <castor@geocast.net>
List: tech-toolchain
Date: 10/25/1998 23:34:37
On Sun, 25 Oct 1998, Jonathan Stone wrote:
> It looks like I get the same problem with gcc-2.7.2.2+myc1...
I'm confused. You're not seeing same problem if you're getting
assembly output. I die with internal compiler errors like the following:
GNU C version egcs-2.91.57 19980901 (egcs-1.1 release) (mips-geocast-elfbsd) compiled by GNU C version egcs-2.90.27 980315 (egcs-1.0.2 release).
bug.c: In function `f':
bug.c:10: internal error--unrecognizable insn:
(insn 14 12 16 (set (reg:SI 81)
(plus:SI (reg:SI 80)
(const_int 32800))) -1 (nil)
(nil))
/geo/src/netbsd-1.3/src/usr/src/gnu/dist/gcc/toplev.c:1360: Internal compiler error in function fatal_insn
> > > struct biggy {
> > > char buf[32800]; /* len further than 16 bit offset */
> > > char len [10 ];
> > > };
> > >
> > > static
> > > void f ( struct biggy * s, int v)
> > > {
> > > s->len[v] = 13 ;
> > > }
> so our intree egcs and gcc2.7.2.2. generate the same code: one outputs
> 13 in decimal and the other in hex. The problem is the immediate
> offset 32800 that doesnt fit in 16 bits. Is that what you get? is
> the assembler supposed to synthesize the instruction with the too-big
> offset, or what? binutils 2.8.1 certainly doesnt seem to do so:
My binutils 2.8.1 cross environment has no problems synthesizing the
instruction sequence. The sequence looks something like
lui $at, 0x1 # $at = <- 65536
addu $at, $at, v0
sb $v1, -32736($at) # $v0[65536 - 32736] = $v1
So, while there's a negative offset, it's clearly the right thing to do.
> Compiling with -dp shows that the pattern used is mips.md:
> movqi_internal2/6, which is indeed dst class 'm'.
>
> So I think the problem (if there is one) is that the C code in
> mips_move_1word is supposed to do the load via loading the offset into
> $at and adding, but it isnt handling this case properly. (or is the
> assembler supposed to fake this up? that would rather make a mockery
> of the insn-size tradeoffs in egcs...)
As I said earlier, since you're getting assembly code, it looks like
there's some difference between the cross compilation and native
environments. Darn.
-castor