[comp.lang.c] 386 unix

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