🚀 go-pugleaf

To whom it may concern,

The bug described below shows a severe incompatibility between
`gcc' and the SUN `cc' compiler for the SPARC architecture.
Here's the relevant data 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 -S bug.c
	5) md:			sparc.md
	6) tm.h:		tm-sparc.h
	7) Problem:		Incompatibility passing aggregates
				by value.

When passing aggregates by value, GCC pushes the contents of the
aggregate onto the stack.  CC, however, allocates temporary storage
for these aggregates in the caller and passes a pointer to the
temporary storage.  Unfortunately, many system routines accept
`struct timeval' aggregates and this incompatibility makes it
difficult to use GCC for system-level programming on SPARC.

Heres a trivial procedure that illustrates the bug:

foo()
  {
  static struct { int a, b; } s = { 0, 1 };

  baz( s );
  }

-------------Compiled with `gcc -O -S bug.c'---------------
gcc_compiled.:
.data
	.align 4
_s.0:
	.word 0
	.word 1
.text
	.align 4
.global _foo
	.proc 1
_foo:
	!#PROLOGUE# 0
	save %sp,-112,%sp
	!#PROLOGUE# 1
	sethi %hi(_s.0),%o1
	or %lo(_s.0),%o1,%o1
	ld [%o1],%o0    <-- NOTE: GCC just passes values in %o0 and %o1
	call _baz,0
	ld [%o1+4],%o1
	ret
	restore

-------------Compiled with `cc -O -S bug.c'---------------
	.seg	"text"			! [internal]
	.proc	4
	.global	_foo
_foo:
!#PROLOGUE# 0
!#PROLOGUE# 1
	save	%sp,-104,%sp
	sethi	%hi(L16),%o1
	or	%o1,%lo(L16),%o1	! [internal]
	ld	[%o1],%o2
	ld	[%o1+4],%o1
	add	%sp,LP12,%o0
	st	%o2,[%o0]    <--- NOTE: CC passes pointer to storage in %o0
	call	_baz,1
	st	%o1,[%o0+4]
	ret
	restore	%g0,0,%o0
LP12	=	96
	.seg	"data"			! [internal]
	.align	4
L16:
	.word	0
	.word	1
------------------------------------------------------------

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