It looks like I get the same problem with gcc-2.7.2.2+myc1...


> >Here's an example of the code which kills it.
> >
> >	Regards,
> >	Castor
> >
> >	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 ;
> >	}


Well, i tried this with egcs from the netbsd tree as at sep 29, and
using -O2 in both cases, i get the same output as with gcc
2.7.2.2+myc1, modulo local-label and ident comments:

diff -wu regress-2722.S regress-egcs.S

--- regress-7272.S      Sun Oct 25 22:06:25 1998
+++ regres-egcss.S   Sun Oct 25 22:06:44 1998
@@ -1,13 +1,4 @@
        .file   1 ""
-
- # GNU C 2.7.2.2+myc1 [AL 1.1, MM 40] NetBSD/mips compiled by GNU C
-
- # Cc1 defaults:
- # -mgas
-
- # Cc1 arguments (-G value = 0, Cpu = 3000, ISA = 1):
- # -version -o -O2
-
 gcc2_compiled.:
 __gnu_compiled_c:
        .text
@@ -19,9 +10,9 @@
        .mask   0x00000000,0
        .fmask  0x00000000,0
        addu    $4,$4,$5
-       li      $2,0x0000000d           # 13
+       li      $2,13                   # 0xd
        sb      $2,32800($4)
        j       $31
        .end    f
-.Lfe1:
-       .size    f,.Lfe1-f
+$Lfe1:
+       .size    f,$Lfe1-f


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:
it assembles happily but disassembles with a negative offset.
(does that make two PRs?)

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...)