mark@digi-g.UUCP (Mark Mendel) (09/11/84)
I have discovered a bug in our C compiler (Pixel Computer Inc., Version 1.2,
3/9/84). Since this bug caused a core dump in the net.sources game PHANTASIA
and many people have been CLUTTERING that group with complaints about a core
dump, I am guessing that this bug is more wide spread. I believe our compiler
is of Unisoft derivation.
Attached is a short program to determine if you suffer from the bug.
The bug is: fcmp(), the compiler's floating point comparison routine, destroys
regiser d0. This is only a problem if a floating comparison is used as PART of
an expression: previously computed sub-expressions are trashed.
[in PHANTASIA, the routine printloc() uses such an expression as an array
subscipt, which caused a core dump].
The fix (if you can't fix the compiler): given an expressions like:
...+(x>1.0)+...
where x is a floating point variable, replace it with:
tmpint = (x>1.0); ...+ tmpint + ...
===================== cut here =====================
#include <stdio.h>
main()
{
double x = 1.0, y = 1.0;
int i;
i = (x > 0) + 2*(y>0);
printf ("%d\n", i);
if (i != 3)
printf("your compiler has problems.\n");
}
hamilton@uiucuxc.UUCP (09/13/84)
i reported this problem a while back (in net.micro, i think); it's effects are even more widespread. my UniSoft C compiler reuses one half of the double result "register" as a scratchpad. you'll see similar problems with code like: double x[], atof(); x[i] = atof(...); the low-order fraction bits from the "atof" will get stomped by the index calculation. i "solved" my problem by avoiding "double"s altogether. i reported the problem to my micro vendor, who promised to pass the word on to unisoft. this was like last march... haven't heard another word about it since. wayne ({decvax,ucbvax}!pur-ee!uiucdcs!uiucuxc!)hamilton