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."