Path: utzoo!utgpu!water!watmath!grand!rwwetmore
From: rwwetmore@grand.waterloo.edu (Ross Wetmore)
Newsgroups: comp.unix.xenix
Subject: Re: SCO Xenix 386 infinite spill
Message-ID: <21805@watmath.waterloo.edu>
Date: 29 Oct 88 00:58:24 GMT
References: <225@milhow1.UUCP> <8362@alice.UUCP>
Sender: daemon@watmath.waterloo.edu
Reply-To: rwwetmore@grand.waterloo.edu (Ross Wetmore)
Distribution: world
Organization: U. of Waterloo, Ontario
Lines: 43

In article <8362@alice.UUCP> debra@alice.UUCP () writes:
>In article <225@milhow1.UUCP> how@milhow1.UUCP (Mike Howard) writes:
>>Background: I am putting up TeX on an SCO Xenix 386 system using the
>> web2c distribution.  The vanilla SYSV distribution is translating
>> and compiling without errors except that the compiler dies on an
>> `infinite spill' error.

>Most infinite spill-problems I have seen all are of the form
>array1[array2[some index expression]+some expression]=
>array1[array2[array3[expression]+expression]+expression];
>or something like that. A combination of array-indexes cause the compiler
>to choke.
>But I believe the problem is even more subtile: taking the one expression
>out of its context makes the problem go away. Obviously the compiler is
>incrementing a counter somewhere and when it doesn't advance far enough in
>the source-code for a number of counter-increments it decides that it is
>in an infinite spill.

>|debra@research.att.com   | uunet!research!debra     | att!grumpy!debra |

  Most of my examples are just complexity of nesting operations. I believe
if you try to compile the GNU gcc compiler v1.25-6, or the game program
'world' you will find interesting examples.

  World has an abominable sequence of if/then/else if's. Adding returns and
removing most of the else's gets you through.

  Gcc is straight complexity with several levels of switch and if's which
finally dies on a multi dimension array access with complex logical 
expressions as indices. Creating temp variables to store the final array
lookup value outside the innermost if fixes the problem.

  I think some poor internal counter or stack just falls off the deep end.

  While I am here, does anyone know if the 'masm' routines in gcc actually
generate Xenix MASM assembler output, and if so is there a missing machine
dependent header file or the like to complete the package? Is anyone actually
using gcc on a Xenix machine? If so, at what rev or how did you do it?

Ross W. Wetmore                 | rwwetmore@waterloo.NetNorth
University of Waterloo          | rwwetmore@math.Uwaterloo.ca
Waterloo, Ontario N2L 3G1       | {uunet, ubc-vision, utcsri}
(519) 885-1211 ext 3293         |   !watmath!rwwetmore