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