[comp.unix.xenix] What does "Infinite Spill" error message indicate?

peter@citcom.UUCP (Peter Klosky) (10/13/87)

We tried compiling a C program which gave the "Infinite Spill"
compiler error.  Does anyone know what causes this message?
It occurs under both  2.2 and 2.1.3 SCO.  None of the people
here have any idea what the problem is, and a call to SCO
did not reveal anything technical; just a lot of listening to
recorded messages and searching for serial numbers.

-- 
Peter Klosky, Citcom Systems (materiel de telecommunications)
seismo!vrdxhq!baskin!citcom!peter (703) 689-2800 x 235

peter@citcom.UUCP (Peter Klosky) (10/14/87)

> We tried compiling a C program which gave the "Infinite Spill"
> compiler error.  Does anyone know what causes this message?

After keeping us waiting for a day or two, SCO got back to us and
we are glad they did; they had seen the problem with the
compiler before and had a work-around ready.  I will try to
summarize the problem in case anyone else runs into it.

The expression in question compiled under 2.1.3 but would not
compile under the new 2.2.0 we bought this month.  According to
SCO tech support, the problem with the C compiler surfaces when
you have a pointer to a structure and try to use an 
integer in the structure to index into an array in the structure.
According to SCO, this problem existed in 2.1.3 but was
repaired in the 2.2.0 release.  Our finding is that the problem
did not exist under 2.1.3 but was introduced as a feature of
the 2.2.0 release.  The work-around is to use a temporary 
variable to store the index, then replace the expression in
the existing statement with the newly introduced temporary 
variable.
-- 
Peter Klosky, Citcom Systems (materiel de telecommunications)
seismo!vrdxhq!baskin!citcom!peter (703) 689-2800 x 235

baron@transys.UUCP (Joe Portman) (10/17/87)

In article <99@citcom.UUCP> peter@citcom.UUCP (Peter Klosky) writes:
>We tried compiling a C program which gave the "Infinite Spill"
>compiler error.  Does anyone know what causes this message?
>It occurs under both  2.2 and 2.1.3 SCO.  None of the people
>here have any idea what the problem is, and a call to SCO
>did not reveal anything technical; just a lot of listening to
>recorded messages and searching for serial numbers.


I have seen this question a few times and experienced the problem a few times.

Eric Griswold of SCO explained it to me as follows:

Infinite spill errors occur when the compiler runs out of registers in which
to "spill" intermediate results in a complcated expression. This usuall occurs 
in large and huge model programs. 

The compiler will generate an error message indicating the file and line number
of the offending expression.

Cure:

	Find the offending line and break the expression into smaller discrete
	steps.

	An example:
	

	x = y->z[10].foo * y->z[9].bar;

	example cure:

	int a,b,c;

	a=y->z[10].foo;
	b=y->z[9].bar
	x=a*b;

	
This example may contain errors (so be it) but I hope you get the idea.
Complex pointer and array/structure references in large and huge model programs
will generate the error. Simplifying the expressions will cure the error.

peter@sugar.UUCP (Peter da Silva) (10/22/87)

In article <344@transys.UUCP>, baron@transys.UUCP (Joe Portman) writes:
> Eric Griswold of SCO explained it to me as follows:
> 
> Infinite spill errors occur when the compiler runs out of registers in which
> to "spill" intermediate results in a complcated expression. This usuall occurs 
> in large and huge model programs. 

The compiler is, therefore, broken. Ritchie's PDP-11 compiler had the
same bug, but at least it produced a meaningful error message.

Cure:

	(1) Change the message to something like "expression too complex".

	(2) Get the compiler to stick the intermediate results onto the
	stack, the usual place to put temporaries once you run out of
	registers. If an 8080 can handle the expression with effectively
	only 1 usable register, surely the 8086 can do better.
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.