how@milhow1.UUCP (Mike Howard) (10/26/88)
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. To keep responses sane: I know that the `infinite spill' error is caused by an expression to complex for the compilers simple brain and I know how to simplify specific instances which cause problems. Let's not repeat that information. Information I'm interested in: 1. examples of 386 programs which have caused the compiler to spasm 2. any known syntactic constructions which cause the problem The cause appears to be more than just one simple expression which is too complex: I moved the offending expression to a separate file in order to work on it and the compiler passed it happily. (BTW I tried compiling w/o the -O option and had no success). Eventual Objective: write a filter which recognizes code which will generate this error and re-write it so that the compiler won't barf (most of the time). Reasons for this Objective: the TeX distribution is written in a `language' called Web. Web files contain documentation intermixed with pascal code (loosely - the structure is more complex than that). There are two processors (tangle and weave) which gobble up web and change (delta to the file) files and produce pascal source or a TeX'able program listing. There is an established kludge which eats the pascal source and produces appropriate C code for compilation on a number of systems. The ideal solution is to insert an `infinite spill detector/fixer' into the kludge so that the Xenix family can join the already established and supported TeX user community. At least this is my puny understanding of things (please don't tell me about other TeX distributions - I barely have time to work on the U of Washington version). Thanks in advance -- Mike Howard uunet!milhow1!how
debra@alice.UUCP (Paul De Bra) (10/28/88)
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. A sufficient way to get rid of the infinite spill messages is to never index an array with another array-reference. But doing this automatically generates a large number of temporary variables. Paul. -- ------------------------------------------------------------------------- |debra@research.att.com | uunet!research!debra | att!grumpy!debra | -------------------------------------------------------------------------
rwwetmore@grand.waterloo.edu (Ross Wetmore) (10/29/88)
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