🚀 go-pugleaf

To whom it may concern,

The bug described below illustrates a bug in the handling of
variable length argument lists on the SPARC architecture.
The code from which this bug manifested itself is rather lengthy
however the symptoms are rather obvious and, hopefully, easy
to correct.  Here are the relevant statistics regarding the compilation:

	1) GCC Version:		1.34
	2) Processor Type:	SPARC (SUN-4)
	3) Operating System:    SUNOS 4.0.3
	4) Command Line:	gcc -O	(optimized compilation)
	5) md:			sparc.md
	6) tm.h:		tm-sparc.h
	7) Problem:		GCC occasionally corrupts variable length
				arg lists by placing an instruction before
				the __builtin_saveregs call which steps
				on `i0' through `i5'.

Here is some assembler output from GCC which illustrates the problem:

(gdb) x/20i &outdb$symbol
0xc3aac <outdb$symbol>: save sp,0xffffff78,sp
0xc3ab0 <outdb$symbol+4>:       or g0,0x64,i4
0xc3ab4 <outdb$symbol+8>:       call 0x1098a0 <__builtin_saveregs>
0xc3ab8 <outdb$symbol+12>:      st i4,[fp-0x18]
0xc3abc <outdb$symbol+16>:      st i0,[fp+0x44]
0xc3ac0 <outdb$symbol+20>:      or g0,0x0,l2
0xc3ac4 <outdb$symbol+24>:      call 0x5db00 <formscope>

NOTE: the `or g0,0x64,i4' which steps on the fifth argument to the
procedure.  Could the __builtin_saveregs call always be placed
immediately after the `save' instruction and never be rearranged
during optimization?

I haven't been able to condense the C code into a small example yet,
however almost any procedure which uses `varargs.h' argument lists
winds up with an extra instruction rearranged before the __builtin_saveregs
call.  If that instruction happens to use one of the `ins', GCC steps on
the argument list.  Send me a reply if you need more info.

Jon Olson, Modular Mining Systems
	   1210 E. Pennsylvania St.
	   Tucson, AZ 85714

USENET:     {allegra,cmcl2,hao!noao}!arizona!modular!olson
INTERNET:   modular!olson@arizona.edu