norstar@tnl.UUCP (Daniel Ray) (08/05/89)
When attempting to compile Conquer 4 under the XENIX 386 2.2 devel. system,
the Microsoft C compiler yields the error:
Compiler error (Internal): Infinite spill
when compiling the module 'navy.c'. If any XENIX people out there know of
a fix, could you please email me information??
Thank-you all.
norstar
The Northern Lights, Burlington Vermont | Oh
tnl dialins: 802-865-3614 at 300-2400 bps. ` | /
------------------------------------------ --- * --- Nooo
uucp: uunet!uvm-gen!tnl!norstar or / | . oo
{decvax,linus}!dartvax!uvm-gen!tnl!norstar | ooooh!chad@lakesys.UUCP (D. Chadwick Gibbons) (08/05/89)
In article <221@tnl.UUCP> norstar@tnl.UUCP (Daniel Ray) writes: |the Microsoft C compiler yields the error: | Compiler error (Internal): Infinite spill This happens in quite a few programs when trying to compile them on any MicroSoft compiler. The problem is due to the way the compiler handlers register declerations. Too many register decelerations are supposed to be ignored, but they wind up confusing the cheap compiler. There is only one fix, but it can be done in two ways: a) remove all register decelerations for a given function, or b) remove one at a time, starting with the one which caused the error My experience has shown that generally this requires option "a" for some strange reason. Usually a function will get this if everything in it is made register, and it has more than seven register declerations...programs to look for this include practiaclly any game written: moria, nethack 3.0, omega, etc. -- D. Chadwick Gibbons, chad@lakesys.lakesys.com, ...!uunet!marque!lakesys!chad
kayvan@mrspoc.Transact.COM (Kayvan Sylvan) (08/07/89)
I had this problem with NetHack3.0 for some files.
It seems that the Microsoft Compiler's register allocation is amazingly
buggy (f**ked up, if you ask me!!!).
Nethack contains many functions which had the form:
function()
{
register int a; register int b; register int c;...
[...]
}
On some of the files, I got the infinite spill message.
My workaround was to include the line:
#define register
in the source files that complained and it compiled and ran beautifully.
---Kayvan
--
Kayvan Sylvan @ Transact Software, Inc. -*- Los Altos, CA (415) 961-6112
Internet: kayvan@Transact.COM -*- UUCP: ...!{apple,pyramid,mips}!mrspoc!kayvannorstar@tnl.UUCP (Daniel Ray) (08/10/89)
Thanks for the responses on the Microsoft cc infinite spill errors. I found
another strange quirk, that allowed me to compile conquer:
I used the MEDIUM 286 memory model (-Mm2). The small was too small (barfed
on update.c), and both the LARGE 286 amd (SMALL) 386 produced spills, altho
in different files (the LARGE 286 barfed immediately when make'ing combat.c,
while the 386 spilled on navy.c).
The MEDIUM model worked all the way thru the make. I'll try the suggested
fixes involving register declarations. Seems like much of compiling is the
art of fiddling with different features, try try again, til it works....
norstar
The Northern Lights, Burlington Vermont | Have conquer...
tnl dialins: 802-865-3614 at 300-2400 bps. ` | / now all I need is
------------------------------------------ --- * --- another 2 megs
uucp: uunet!uvm-gen!tnl!norstar or / | . of ram!
{decvax,linus}!dartvax!uvm-gen!tnl!norstar | martin@zeus.hf.intel.com (Martin Wilde) (08/11/89)
In article <221@tnl.UUCP>, norstar@tnl.UUCP (Daniel Ray) writes: > > When attempting to compile Conquer 4 under the XENIX 386 2.2 devel. system, > the Microsoft C compiler yields the error: > > Compiler error (Internal): Infinite spill > > when compiling the module 'navy.c'. If any XENIX people out there know of > a fix, could you please email me information?? > > Thank-you all. > Without having seen the module in question I have generally found that reducing the number of variables declared to be register variables can get rid of this problem. Another solution would be to examine the code around the line(s) giving the problem and reducing their complexity. _/_ | ______ __. __ / o ____ | textronix!reed!littlei!zeus:martin / / / <_(_/|_/ (_<__<_/ / < | | martin@clubmed.hf.intel.com |