bob@rel.eds.com (Bob Leffler) (02/12/88)
When attempting to compile rn 4.3 the other day with the Xenix 286 2.2
compiler, I got the following error:
rcln.c(50) : Compiler error (internal):Infinite spill
This error isn't in the documentation. I'm curious as to what caused the
error and what it actually means.
--
Bob Leffler - EDS, GM Truck & Bus Account (313)456-5375
bob@rel.eds.com or {rutgers, uunet!edsews}!rel!bob
Opinions expressed may not be those of my employer.kevinr@june.cs.washington.edu (Kevin Ross) (02/13/88)
In article <515@rel.eds.com> bob@rel.eds.com (Bob Leffler) writes: >When attempting to compile rn 4.3 the other day with the Xenix 286 2.2 >compiler, I got the following error: > >rcln.c(50) : Compiler error (internal):Infinite spill I have been running into the same error. I called SCO, but got the standard put off, and a 'we will note the bug'. It seems to stem from the -LARGE compiler model. I was successful in compiling my program by NOT using it. My guess is that the LARGE model compiler has a bug in the symbol table routines. Kevin kevinr@june.cs.washington.edu ..beaver!june!kevinr
wrp@biochsn.acc.virginia.edu (William R. Pearson) (02/13/88)
In article <515@rel.eds.com> bob@rel.eds.com (Bob Leffler) writes: >When attempting to compile rn 4.3 the other day with the Xenix 286 2.2 >compiler, I got the following error: > >rcln.c(50) : Compiler error (internal):Infinite spill > This error has been around for a very long time. I have always found it associated with an expression of the form: str->mem[i++]; You can get rid of it by rearranging: str->mem[i]; i++; Bill Pearson wrp@virginia.EDU
karl@ddsw1.UUCP (Karl Denninger) (02/15/88)
In article <4218@june.cs.washington.edu> kevinr@uw-june.UUCP (Kevin Ross) writes: >In article <515@rel.eds.com> bob@rel.eds.com (Bob Leffler) writes: >>When attempting to compile rn 4.3 the other day with the Xenix 286 2.2 >>compiler, I got the following error: >> >>rcln.c(50) : Compiler error (internal):Infinite spill > >I have been running into the same error. I called SCO, but got the standard >put off, and a 'we will note the bug'. > >It seems to stem from the -LARGE compiler model. I was successful in compiling >my program by NOT using it. Well, if you don't need -LARGE that's ok ;-) What happens when you have a 500k program? >My guess is that the LARGE model compiler has a bug in the symbol table >routines. Try adding this to the compiler options: -Dregister= (that's nothing following the '=') We've seen this on the '386 system, and in every case so far putting in this DEFINE cures the problem... Strangely, I've only seen the program when there are 'register' declarations.... Perhaps that is related. ----- Karl Denninger | Data: +1 312 566-8912 Macro Computer Solutions, Inc. | Voice: +1 312 566-8910 ...ihnp4!ddsw1!karl | "Quality solutions for work or play"
drew@vrdxhq.UUCP (Drew Johnson) (02/17/88)
In article <4218@june.cs.washington.edu> kevinr@uw-june.UUCP (Kevin Ross) writes: >In article <515@rel.eds.com> bob@rel.eds.com (Bob Leffler) writes: >>When attempting to compile rn 4.3 the other day with the Xenix 286 2.2 >>compiler, I got the following error: >> >>rcln.c(50) : Compiler error (internal):Infinite spill I got this 'Infinite spill' message left and right when trying to compile the game 'Omega' on my Xenix286 box. I believe the problem is linked to the compiler's limitation on single line expressions. Trying something like: x[y[z.a.b->c][d.e->f]] is beyond the poor Xenix C compiler's ability to calculate. Every time that I got this error, it was corrected by spreading calculations such as the one above over two or more instructions. I am betting that this will not be fixed in the near future, but SCO may come up with a more informative error statement. Drew D. Johnson vrdxhq!drew
ericg@sco.COM (Mwa ha ha) (02/17/88)
karl@ddsw1.UUCP (Karl Denninger) wrote in article <727@ddsw1.UUCP]:
]In article <4218@june.cs.washington.edu] kevinr@uw-june.UUCP (Kevin Ross) writes:
]]]rcln.c(50) : Compiler error (internal):Infinite spill
]]
]Try adding this to the compiler options:
]
] -Dregister=
]
](that's nothing following the '=')
]
Though I cannot vouch for this curing the problem, a slightly safer approach
(that won't break declarations like 'register foo') would be:
-Dregister=auto
]Karl Denninger | Data: +1 312 566-8912
--
Eric Griswold (ericg@sco.COM)
"That's no baby. That's a Mr. Potatohead"
I do not speak for SCO, I barely have enough room for my own opinions.andrew@riddle.UUCP (Andrew Beattie) (02/17/88)
>rcln.c(50) : Compiler error (internal):Infinite spill It means something to the effect of "this line is to complex for me to compile, please make it simpler." It is likely to be a line containing pointers, arrays and structures and the error is more likely to occur when using larger compiler models (because the compiler has to generate more complex code to cope with the offsets and stuff). The workround is to split the line up (perhaps using temporary variables to give the compiler less to think about at one time.) Note that in HUGE model, the lines that are barfed can look remarkably simple. >This error isn't in the documentation. Have a rummage through your release notes and the "cc and ld error messages" section. I can't find it just now but I have read it before. Andrew
geo@Alliant.COM (George Aguiar) (02/18/88)
In article <632@nod2sco> ericg@sco.COM (Mwa ha ha) writes: >karl@ddsw1.UUCP (Karl Denninger) wrote in article <727@ddsw1.UUCP]: >]In article <4218@june.cs.washington.edu] kevinr@uw-june.UUCP (Kevin Ross) writes: >]]]rcln.c(50) : Compiler error (internal):Infinite spill I had a similar problem porting uemacs 3.9 to XENIX, but I think it was 2.1.1. Anyway, look on line 50 of rcln.c for a auto-incrementing index to an array. Something like: foobar[counter++]; Change it to: foobar[counter]; counter++; That should fix it! -- geo uucp: geo@alliant.Alliant.COM at&t: 617-486-1372 weee: N4300F "What comes around goes around."