dave@sdeggo.UUCP (09/25/87)
In article <380@micropen>, dave@micropen (David F. Carlson) writes: > Are there any beta sites that can confirm or deny these rather reasonable > claims? Has anyone *ever* had a demonstrable, verifiable compiler bug > with the Microport PCC-based compiler? > -- > David F. Carlson, Micropen, Inc. > ...!{seismo}!rochester!ur-valhalla!micropen!dave > > "The faster I go, the behinder I get." --Lewis Carroll There are two compiler bugs which I know of. One was apparently introduced when the compiler was ported to the 80286, since a statement of the form: struct dummy { char z[1000]; }; struct dummy * x[100][100]; will generate a "array too large" error, however, if you substitute char * for struct dummy * it will pass it (and it will work too). That's a nice little math mistake, since it appears that they're taking the size of the structure instead of the size of the pointer to the structure. The following program causes the compiler to screw up the assembly language it outputs: #include <stdio.h> main() { double test; test=0.0000001; printf("test is %f\n",test); } Here is the output: .file "test.c" .data .text .def main; .val main; .scl 2; .type 044; .endef .globl main main: enter $.F1,$0 .data .even .29: .double :e-08 ^^ the assembler doesn't like this line, which should be 1e-06. It only dies on this particular number (well, I haven't done an exhaustive search, but other numbers in this range do not replicate the problem) and only if the variable is a double. .text lea -8(%bp),%di mov $.29,%si mov $4,%cx rep smov (%si),(%di) .text lea -8(%bp),%si sub $8,%sp mov %sp,%di mov $4,%cx rep smov (%si),(%di) push $.31 call printf add $10,%sp .28: leave ret .def main; .val .; .scl -1; .endef .set .T1,1 .set .S1,0 .set .F1,8 .data .31: .string "test is %f\n" ----- There have also been quite a few problems with int <-> floating point casts, though this may just be caused by 16 bit ints. It tends to come up with some very bizarre numbers at times. The structure size bug is definitely the most annoying to me, since it breaks a large amount of exsisting code and requires doing a lot of casts on char * arrays to make things work. The .0000001 bug is more annoying than anything else, but it took quite a while to pin down, since the first time it popped up for me was in the middle of compiling empire, and no one at Microport could explain the assembler format so I could determine what line number it had occured at. Messy! -- David L. Smith {sdcsvax!amos,ihnp4!jack!man, hp-sdd!crash, pyramid}!sdeggo!dave sdeggo!dave@amos.ucsd.edu "How can you tell when our network president is lying? His lips move."
mjy@sdti.UUCP (Michael J. Young) (09/25/87)
In article <98@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >In article <380@micropen>, dave@micropen (David F. Carlson) writes: >> Are there any beta sites that can confirm or deny these rather reasonable >> claims? Has anyone *ever* had a demonstrable, verifiable compiler bug >> with the Microport PCC-based compiler? I don't know anything about the 386 compiler, but the following code breaks the 286 compiler: int *alloc(); int kl() { int s; char *am; (am == 0) ? (am = (char *) alloc((long) s)): 0; } Compiling the above function in large memory model causes an internal compiler error : register allocation error. The generated code (up until the compiler aborts) is: .file "t1.c" .data .text .def kl; .val kl; .scl 2; .type 044; .endef .globl kl kl: enter $.F1,$0 test -4(%bp) jne .10000 test -6(%bp) jne .10000 .10001: mov -2(%bp),%ax cwd push %dx push %ax lcall alloc add $4,%sp mov %ax,-6(%bp) mov %dx,-4(%bp) jmp .10002 .10000: xor %ax,%ax xor %dx,%dx .10002: mov %ax,%bx ; oops! mov %bx,%ax I'd be interested to hear if this problem is also present in the 386 compiler. The conditional construct that causes wedges the compiler is frequently generated by C++. In fact, the code fragment I included here was given to us by Bjarne Stroustrup as proof that C++ could not easily be ported to a 286 machine that used the intel pcc-based compiler. (I have heard that other non-pcc-based compilers, such as Metaware's High-C, do not have this problem). Anyone with a beta copy of System V/386 care to try it and see if it works? -- Mike Young - Software Development Technologies, Inc., Sudbury MA 01776 UUCP : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy Internet : mjy%sdti.uucp@harvard.harvard.edu Tel : +1 617 443 5779