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