root@libove.UUCP (The Super User) (06/04/88)
Can someone please explain why a slightly too complex expression can cause the large model pass of the SCO Xenix 2.1.4g compiler to generate a compiler "infinite spill" error? What *exactly* does that mean? Basically, expressions like structptr->elt_struct.struct_item = int + str->elt.str; will cause the infinite spill error, and this can be corrected by: junkvar = str->elt.str; structptr->elt_struct.struct_item = int + junkvar; So, WHAT IS IT? Thanks- -- Jay Libove (Jay.Libove@andrew.cmu.edu or pitt!darth!libove!libove)
greg@gryphon.CTS.COM (Greg Laskin) (06/09/88)
In article <25@libove.UUCP> root@libove.UUCP (The Super User) writes: > >Can someone please explain why a slightly too complex expression can >cause the large model pass of the SCO Xenix 2.1.4g compiler to generate >a compiler "infinite spill" error? What *exactly* does that mean? > It means the expression is to complex. The compiler ran out of internal registers while attempting to generate the code. The message could, perhaps, have been more descriptive, but is likely quite accurate from the compiler writer's perspective. -- Greg Laskin greg@gryphon.CTS.COM <any backbone site>!gryphon!greg
kevinr@june.cs.washington.edu (Kevin Ross) (06/09/88)
In article <25@libove.UUCP> root@libove.UUCP (The Super User) writes: >Can someone please explain why a slightly too complex expression can >cause the large model pass of the SCO Xenix 2.1.4g compiler to generate >a compiler "infinite spill" error? What *exactly* does that mean? >Basically, expressions like >structptr->elt_struct.struct_item = int + str->elt.str; >will cause the infinite spill error, and this can be corrected by: >junkvar = str->elt.str; >structptr->elt_struct.struct_item = int + junkvar; >Jay Libove (Jay.Libove@andrew.cmu.edu or pitt!darth!libove!libove) The problem is in the way the 80286 does pointer arithmetic. Actually, it is a compiler error, since this shouldn't be a problem. If you create an expression that contains too many indirections, the compiler tries its hardest to create the code. However, it runs out of ways to get at the data, since there are a limited number of registers that can do indirect loads. There really is no excuse for this, just the reason. I have been fighting the same damn problem every since I got XENIX. You made the proper adjustment to the code, and it is the only solution. The XENIX 2.1.4 compiler is very buggy. If I had the money, I would get the 2.2.1 version, but I don't, so I won't. Kevin kevinr@june.cs.washington.edu Home: ...beaver!tikal!camco!carmine!kevin
greg@gryphon.CTS.COM (Greg Laskin) (06/12/88)
In article <5087@june.cs.washington.edu> kevinr@uw-june.UUCP (Kevin Ross) writes: >The XENIX 2.1.4 compiler is very buggy. If I had the money, I would get the >2.2.1 version, but I don't, so I won't. > Very buggy, as opposed to what? ( 2.2.1 has its own set of bugs as does every compiler for any language. The bug list for the 2.1.4 compiler was about 4 pages long, with two to three bugs per page, mostly concerning large model, floating point and bitfield operations. ) -- Greg Laskin greg@gryphon.CTS.COM <any backbone site>!gryphon!greg
amull@Morgan.COM (Andrew P. Mullhaupt) (11/24/89)
When I have compiler errors in cc or rcc under SCO UNIX System V/386 r3.2 I only get the error number, not the text, (or the helpful indication of which identifier is undefined, etc.). Now I can find the files containing the error texts, but maybe cc can't. Any suggestions? I can't get much response from the manuals, but then again there are a lot of possible places to look which elude me; on-line (the infamous UNIX 'man' system) doesn't help me yet, either. Thanks in advance, Andrew Mullhaupt
jtc@van-bc.UUCP (J.T. Conklin) (11/25/89)
In article <529@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes: >When I have compiler errors in cc or rcc under SCO UNIX System >V/386 r3.2 I only get the error number, not the text, (or the >helpful indication of which identifier is undefined, etc.). I think that the lack of comprehensive diagnostics is the most serious drawback of the present SCO UNIX/XENIX C compilers. Given the compiler technology availiable today, there is absolutely no excuse for poor diagnostics. For example, I would expect the following code: #include <stdio.h> main(argc, argv) { printf("hello, world!\n") printf("%d, %d\n", foo bar); } to produce error messages similar to the following: cc1: Warning: foo.c: line 5: Inserting Missing Semicolon printf("hello, world!\n") ----------------------------^ cc1: Error: foo.c: line 6: Undefined Identifier printf("%d, %d\n", foo bar); ----------------------^ cc1: Warning: foo.c: line 6: Inserting Missing Comma printf("%d, %d\n", foo bar); -------------------------^ cc1: Error: foo.c: line 6: Undefined Identifier printf("%d, %d\n", foo bar); ---------------------------^ I realize that the Microsoft C compiler comes from a marketplace which judges compilers solely on compilation speed, and the size and execution speed of the binaries they produce, but I don't think this is an unreasonable request. --jtc -- J.T. Conklin ...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.ca
timk@xenitec.on.ca (Tim Kuehn) (11/26/89)
In article <69@van-bc.UUCP> jtc@van-bc.UUCP (J.T. Conklin) writes: >In article <529@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes: >I think that the lack of comprehensive diagnostics is the most serious >drawback of the present SCO UNIX/XENIX C compilers. > >Given the compiler technology availiable today, there is absolutely >no excuse for poor diagnostics. Which is probably why Lint(CP) is included in with the development system. Although it doesn't display error messages as comperable to the one's you're looking for (following), the docs state that it "attempts to detect features of the C program <file> that are likely to be bugs, nonportable, or wasteful. >For example, I would expect the following code: > > #include <stdio.h> > > main(argc, argv) > { > printf("hello, world!\n") > printf("%d, %d\n", foo bar); > } > > >to produce error messages similar to the following: > > cc1: Warning: foo.c: line 5: Inserting Missing Semicolon > printf("hello, world!\n") > ----------------------------^ How would a compiler know that's supposed to be a semi-colon and not a math/string/pointer operator of some kind? > cc1: Error: foo.c: line 6: Undefined Identifier > printf("%d, %d\n", foo bar); > ----------------------^ Undefined, missing comma, or extra space? > cc1: Warning: foo.c: line 6: Inserting Missing Comma > printf("%d, %d\n", foo bar); > -------------------------^ Missing comma, math/string/pointer operand or other? While what you ask for sounds *very* nice (and I'd love to have a C compiler that'd do diagnostics like that!) it involves a level of intuiting what the programmer was trying to do, and I for one would rather the compiler just tell me "this is what's wrong, and here's what's wrong with it." rather than just spitting out an error code I'd have to look up in a ref. manual somewhere. To have the compiler modify the code, or how the code behaves, particularly in the case of a error (ie unknown) condition is something that I would *not* want. (How would you know what the compiler's really done with your code then?) (I liked the HP 3000 compilers for that, if the error message wasn't clear enough, you could go to the manual, find the error number, and the manual would tell you more specifically what the error meant and suggest ways to correct the problem.) +-----------------------------------------------------------------------------+ |Timothy D. Kuehn timk@xenitec.on.ca | |TDK Consulting Services !watmath!xenitec!timk | |871 Victoria St. North, Suite 217A | |Kitchener, Ontario, Canada N2B 3S4 (519)-741-3623 | |DOS/Xenix - SW/HW. uC, uP, DBMS. Quality SW Guaranteed | +-----------------------------------------------------------------------------+
chip@vector.Dallas.TX.US (Chip Rosenthal) (11/26/89)
>> cc1: Warning: foo.c: line 5: Inserting Missing Semicolon >> printf("hello, world!\n") >> ----------------------------^ Oh yeah, don't terse error messages stink. For example, on one system I get such wonderfully helpful diagnostic messages like this: ccom: Error: foo.c, line 7: foobar undefined (--( (&_iob[1]))->_cnt < 0 ? _flsbuf((unsigned char) ((foobar)), ( (&_iob[1]))) : (int) (*( (&_iob[1]))->_ptr++ = (unsigned char) ((foobar)))); ----------------------------------------------------------------------- --------------------------------------------------------^ Besides, be careful what you ask for. You might get it. My guess is that folks who want compilers to correct dumb mistakes have never worked with one which did. -- Chip Rosenthal /// chip@chinacat.Lonestar.ORG /// texbell!chinacat!chip ===> By the time you receive this, <chip@vector> will be inactive. ===> Please send replies to <chip@chinacat>.
wain@seac.UUCP (Wain Dobson) (11/26/89)
In article <1989Nov25.204009.246@xenitec.on.ca> timk@xenitec.UUCP (Tim Kuehn) writes: >In article <69@van-bc.UUCP> jtc@van-bc.UUCP (J.T. Conklin) writes: >>In article <529@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes: >>I think that the lack of comprehensive diagnostics is the most serious >>drawback of the present SCO UNIX/XENIX C compilers. Well I really liked the IBM PL/1 Checkout Compiler. So, what stands in the way of producing a checkout compiler for 'C'? The PL/1 Checkout Compiler does make for fast debugging. -- Wain Dobson, Vancouver, B.C. ...!{uunet,ubc-cs}!van-bc!seac!wain
jtc@van-bc.UUCP (J.T. Conklin) (11/26/89)
In article <1123@vector.Dallas.TX.US> chip@chinacat.Lonestar.ORG (Chip Rosenthal) writes: >Oh yeah, don't terse error messages stink. For example, on one system >I get such wonderfully helpful diagnostic messages like this: > >ccom: Error: foo.c, line 7: foobar undefined > (--( (&_iob[1]))->_cnt < 0 ? >_flsbuf((unsigned char) ((foobar)), ( (&_iob[1]))) : >(int) (*( (&_iob[1]))->_ptr++ = (unsigned char) ((foobar)))); > ----------------------------------------------------------------------- >--------------------------------------------------------^ I guess that's the price you have pay to have a separate pre-processor. If it was integrated to the compiler, perhaps the compiler could cashe the line and report the following: ccom: Error: foo.c, line 7: foobar undefined putchar(foobar); ----------^ then again, it would probably be too much of a performance hit. >Besides, be careful what you ask for. You might get it. My guess is >that folks who want compilers to correct dumb mistakes have never worked >with one which did. Although the one compiler I've used that repaired dumb mistakes did an admirable job, I'm unsure of whether or not I'd want to use one today. I would be certain of that if every compiler had adequate diagnostics. If the choice is between terse diagnostics like Microsofts, or the potentially verbose diagnotistics like the MIPS compiler, I assure you I'd take verbosity. --jtc -- J.T. Conklin ...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.ca
jtc@van-bc.f you ar (J.T. Conklin) (11/26/89)
In article <1123@vector.Dallas.TX.US> chip@chinacat.Lonestar.ORG (Chip Rosenthal) writes: >Oh yeah, don't terse error messages stink. For example, on one system >I get such wonderfully helpful diagnostic messages like this: > >ccom: Error: foo.c, line 7: foobar undefined > (--( (&_iob[1]))->_cnt < 0 ? >_flsbuf((unsigned char) ((foobar)), ( (&_iob[1]))) : >(int) (*( (&_iob[1]))->_ptr++ = (unsigned char) ((foobar)))); > ----------------------------------------------------------------------- >--------------------------------------------------------^ I guess that's the price you have pay to have a separate pre-processor. If it was integrated to the compiler, perhaps the compiler could cashe the line and report the following: ccom: Error: foo.c, line 7: foobar undefined putchar(foobar); ----------^ then again, it would probably be too much of a performance hit. >Besides, be careful what you ask for. You might get it. My guess is >that folks who want compilers to correct dumb mistakes have never worked >with one which did. Although the one compiler I've used that repaired dumb mistakes did an admirable job, I'm unsure of whether or not I'd want to use one today. I would be certain of that if every compiler had adequate diagnostics. If the choice is between terse diagnostics like Microsofts, or the potentially verbose diagnotistics like the MIPS compiler, I assure you I'd take verbosity. --jtc -- J.T. Conklin ...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimse
chip@vector.Dallas.TX.US (Chip Rosenthal) (11/27/89)
In article <71@van-bc.UUCP> jtc@van-bc.UUCP (J.T. Conklin) writes: >In article <1123@vector.Dallas.TX.US> chip@chinacat.Lonestar.ORG (Chip Rosenthal) writes: >>ccom: Error: foo.c, line 7: foobar undefined >> (--( (&_iob[1]))->_cnt < 0 ? >>_flsbuf((unsigned char) ((foobar)), ( (&_iob[1]))) : >>(int) (*( (&_iob[1]))->_ptr++ = (unsigned char) ((foobar)))); >> ----------------------------------------------------------------------- >>--------------------------------------------------------^ > >I guess that's the price you have pay to have a separate pre-processor. >If it was integrated to the compiler, perhaps the compiler could cashe >the line and report the following: > >ccom: Error: foo.c, line 7: foobar undefined > putchar(foobar); > ----------^ Not really. Certainly the compiler could get back to the line in the original source file in which the error occurred, much pain is taken with "#line" to maintain this information. However, parsing is being performed upon the cpp output, and correlating the token which caused the error back to the original source file seems non-trivial. The fact that preprocessing is a seperate pass isn't really an issue. The issue is that the code available to the compiler at which time errors are detected is not the same code that you wrote. Two points follow from this. First, given error message one: foo.c(7) : error 65: 'foobar' : undefined and error message two: ccom: Error: foo.c, line 7: foobar undefined putchar(foobar); ----------^ Do you really think error message two will significantly improve your programming productivity? Second, given that sw manufacturers are only going to expend limited resources on compiler designs, wouldn't you really prefer to see that effort placed on better optimizations than this sort of thing? >>Besides, be careful what you ask for. You might get it. >Although the one compiler I've used that repaired dumb mistakes did >an admirable job, I'm unsure of whether or not I'd want to use one today. In my case, it was PL/C. It made sense when we were running batch -- a dropped semicolon meant a good 20-40 minutes to repunch cards and rerun the job. These days, at the cost of a 3 minute edit and recompile, I don't think it's worth it. Again, there are more important things which can be done. >I would be certain of that if every compiler had adequate diagnostics. >If the choice is between terse diagnostics like Microsofts, or the >potentially verbose diagnotistics like the MIPS compiler, I assure >you I'd take verbosity. This isn't a flame on verbose error messages. But rather a plea to make them |just good enuf| for me to figure out the bug, and then spend the rest of the time on more important things. For example, I would much rather have the "inifinite spill" bug fixed rather than a more verbose diagnostic saying more precicely where it is... -- Chip Rosenthal /// chip@chinacat.Lonestar.ORG /// texbell!chinacat!chip ===> By the time you receive this, <chip@vector> will be inactive. ===> Please send replies to <chip@chinacat>.
jtc@van-bc.UUCP (J.T. Conklin) (11/27/89)
>This isn't a flame on verbose error messages. But rather a plea to >make them |just good enuf| for me to figure out the bug, and then >spend the rest of the time on more important things. For example, >I would much rather have the "inifinite spill" bug fixed rather than >a more verbose diagnostic saying more precicely where it is... It seems I flamed Microsoft's diagnostics a bit more harshly than I had intended. They are more than adequate 95% of the time. The linker's diagnostics are a bit worse, but still passable. Here are a number of things that bother me about the current development system -- They all have precidence over verbose error messages. * Fix code generation errors/compiler bugs It took me two days to track down a code generation error last week. Arggh... You've allready mentioned the infinate spill bug. * Generate assembly output acceptable as input to the assmbler "-S ... It should be noted that this file is not suitable for assembly. This option provides code for reading only." * Eliminate hard-coded limits. * yacc's and lex's tables should should resize themselves automatically. * linker should allocate segments automatically. * enlarge compiler's 32 character identifier limit. * Fix compiler such that "cc -E" and "/lib/cpp" produce the same output. * Fix lint. * Improve dubugger support. * Improve optimization. * function inlining? * global register optimization? --jtc -- J.T. Conklin ...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.ca
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/28/89)
In article <72@van-bc.UUCP> jtc@van-bc.UUCP (J.T. Conklin) writes: | * Fix code generation errors/compiler bugs | | It took me two days to track down a code generation error | last week. Arggh... You've allready mentioned the infinate | spill bug. SCO has been quite good about fixing bugs *if I gave them a small example*. The infinite spill should have been fixed years ago. The standard text is "simplify teh expression." I got that even when the expression was "return 1". When I evaluated 386 UNIX versions, all of the pcc based compilers had a bug which caused the compiler to emit source which used registers the assembler (and CPU) didn't have. | | * Generate assembly output acceptable as input to the assmbler | | "-S ... It should be noted that this file is not suitable for | assembly. This option provides code for reading only." I'm not sure this is true anymore. I just tried a small program and it worked okay, and I have used -Fa (I think the same as -S) in the past to generate code to hand massage. I think it's a reluctance to guarantee that it will work all the time. I'm not sure how vital this is, I have only hand done one program in four years, and that was 11 instructions at the heart of a loop executed 600,000,000 times (yes really) which needed to play with the 387 stack. | | * Eliminate hard-coded limits. | | * yacc's and lex's tables should should resize themselves | automatically. Probably. Nice but not high priority. | | * linker should allocate segments automatically. As above. | | * enlarge compiler's 32 character identifier limit. Should match ANSI by default. There is -H to set length of extern names (I never tried it). | | * Fix compiler such that "cc -E" and "/lib/cpp" produce the | same output. yes. | | * Fix lint. That's a generic complaint will all C compilers, guy. | | * Improve dubugger support. Be speciffic. | | * Improve optimization. | | * function inlining? yes. | | * global register optimization? I give this one a "yes, but." It's a good idea, but doesn't produce a huge gain in performance (unless you write a program which deliberately induces bad behavior). Other global stuff can give more performance. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
tanner@cdis-1.uucp (Dr. T. Andrews) (11/29/89)
It is said...
) "Beware of compilers which correct errors".
This is reasonable advice. I don't want the thing to continue and
actually compile/link a program which has errors, even to the extent
of swallowing
printf("blunge") printf("more blunge") /* missing ';' */
On the other hand, I'd sure prefer that to the cascade of errors
which results from certain omissions. Missing punctuation can
generate incredible error cascades using SCO's version of the
Microsoft compiler. A heuristic which, on error, attempted in
some order the insertion of ')', '}', and ';' might be a welcome
diagnostic tool for that "first attempt to compile".
--
Mulroney: "Cut trains. Drive in | {bpa,uunet}!cdin-1!cdis-1!tanner
Canada. We need the acid rain." | {attctc gatech!uflorida}!ki4pv!cdis-1!tannertanner@cdis-1.uucp (Dr. T. Andrews) (11/29/89)
In article <1783@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
) SCO has been quite good about fixing bugs *if I gave them a small
) example*.
They aren't always so good with the Xenix dev system, I fear. The
numbers in the first column are SCO's reference numbers; missing
numbers indicate that the report was never ACKed. Most have been
sent several times. The names "pfc*.*" are the names of the example
files sent along.
r050120 16-Jan-87 _doprnt() fails to work, example "pfc154.c"
r050121 05-Mar-87 lint void * problem (pfc162.c, pfc165.c)
02-May-88 lint function type bug (incl pfc203{a,b}.c)
02-May-88 lint arg type bug (incl pfc205{a,b}.c)
05-May-88 lint "void *" argument bug (incl pfc206.c)
23-Aug-88 lint "register void *" bug (incl pfc222.c)
09-Dec-88 lint blows ternary operator type (pfc234.c)
09-Dec-88 lint blows enum==int usage (pfc235.c)
20-Jan-89 "as" dumps core (pfc237.s)
09-Feb-89 lint fails on "string1" "string2" (pfc239.c)
156680 02-Mar-89 lint blows on extra braces (pfc241.c) ref 58 332
13-Mar-89 dos rename args backwards (pfc243.c)
14-Mar-89 unions of pointers give problem (pfc212.c)
14-Mar-89 lint blows arrays within structs (pfc244.c)
15-Mar-89 compiler error message is wrong (pfc245.c)
s199287 11-Aug-89 that loop-opt bug & friends (pfc253.c)
58702 20-Aug-89 cc -U__STDC__ doesn't work (pfc254.c)
S203098 20-Aug-89 cc blows proto(type, type name) (pfc255.c)
S202045 20-Aug-89 cc dies after blown pfc255 err (pfc256.c)
S203948 30-Aug-89 cc recognizes word "interrupt" (pfc257.c)
58778 26-Sep-89 "lint" blows "register struct" (pfc259.c)
One might suspect that the $Nk/year "softcare" support would be a
better deal if the reports were in fact ACKed, even if no one cared
to actually fix the bugs. Some of thse problem tracking numbers are
so old that they've aged out of the system entirely!
) The infinite spill should have been fixed years ago.
Agreed, but it's fairly rare as long as you don't try to do anything
complex. (Besides, it's not a bug, it's an engineering decision:-)
Anyone having patches to apply to a binary distribution for any of
the compiler or lint bugs is invited to send e-mail. We have the
`386 dev sys (2.3+lng085 update).
--
Mulroney: "Cut trains. Drive in | {bpa,uunet}!cdin-1!cdis-1!tanner
Canada. We need the acid rain." | {attctc gatech!uflorida}!ki4pv!cdis-1!tanneramull@Morgan.COM (Andrew P. Mullhaupt) (11/29/89)
I'm convinced from the replies posted so far that I did not make my problem with C error messages clear. 1. By terse error messages, I mean that the error text normally supplied with the SCO cc compiler is not being printed. Not that if it were printed, it would be too short, but that it is not being reported. That is, I don't get 'Unidentified identifier xxx' but just the error number C2065. Now I think 'C2065' is not descriptive enough. The correct message, according to the C Programmer's guide is 'xxx : undefined' which is what I would like. 2. The problem can be fixed by making sure that links from the files /lib/*.err exist to the /lib/386 directory. The Development tools installation does not always ensure this; which is a bug in my opinion. Apparently you don't get a fully wired compiler unless you include the XENIX cross-development tools in your installation. Later, Andrew Mullhaupt