Path: utzoo!telly!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!FOOBAR.COLORADO.EDU!grunwald
From: grunwald@FOOBAR.COLORADO.EDU (Dirk Grunwald)
Newsgroups: gnu.gcc.bug
Subject: gcc-1.36 DecStation 3100 bug (breaks g++, too)
Message-ID: <8912151730.AA25787@foobar.Colorado.EDU>
Date: 15 Dec 89 17:30:50 GMT
Sender: daemon@tut.cis.ohio-state.edu
Reply-To: grunwald@foobar.colorado.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 40


In-reply-to: ham@Neon.Stanford.EDU's message of 15 Dec 89 00:22:29 GMT

1.37beta produces the same output, however, I don't think it's wrong.
If you assemble & disassemble the source, you get:

  [foo.s:  10] 0x0:     3c010040        lui     at,0x40
  [foo.s:  10] 0x4:     34210010        ori     at,at,0x10
  [foo.s:  10] 0x8:     03a1e823        subu    sp,sp,at
  [foo.s:  11] 0xc:     afbe0000        sw      s8,0(sp)
  [foo.s:  13] 0x10:    3c0f0040        lui     t7,0x40
  [foo.s:  14] 0x14:    35ef0010        ori     t7,t7,0x10
  [foo.s:  15] 0x18:    03aff021        addu    s8,sp,t7
  [foo.s:  18] 0x1c:    001e4021        addu    t0,zero,s8
  [foo.s:  20] 0x20:    3c1effc0        lui     s8,0xffc0
  [foo.s:  20] 0x24:    03c8f021        addu    s8,s8,t0
  [foo.s:  20] 0x28:    8fdefff0        lw      s8,-16(s8)
  [foo.s:  23] 0x2c:    03e00008        jr      ra
  [foo.s:  22] 0x30:    0008e821        addu    sp,zero,t0

the MIPS assembler quietly converts insns like
	subu	$29,4194312	# saveregs=    8
into
  [foo.s:  10] 0x0:     3c010040        lui     at,0x40
  [foo.s:  10] 0x4:     34210010        ori     at,at,0x10
  [foo.s:  10] 0x8:     03a1e823        subu    sp,sp,at

the 'lui' insn loads the upper half of 'at'(..a temporary register
allocated to the assembler for just this purpose) , clearing the lower
half and the 'ori' sets the lower half.

when you reach the 'subu' you'll have 0x400010 in the at register; the
subtract should then work as expected.

Perhaps the MIPS backend should be changed to do these things
explicitly, I dunno. It might allow more optimizations (sharing of
similar high parts, etc) than the current scheme.

Dirk Grunwald -- Univ. of Colorado at Boulder	(grunwald@foobar.colorado.edu)
						(grunwald@boulder.colorado.edu)