robert@swanee.ee.uwa.oz.au (Roberto Togneri) (01/08/91)
Here's a real interesting problem for you:
History: One of our Personal Irises (4D/20) had a hardware failure and we got
a replacement electronics module from SGI. After installing and running the
diagnostics on it which it passed some users complained that they were
getting funny answers to some of their programs. I was surprised that by
the results from running the following program:
#include <stdio.h>
main()
{
double a;
a = 1234.5678;
printf("%lf\n",a);
}
Here's the script file of the run (note that odin is the defective machine;
the local one works correctly):
Script started on Tue Jan 8 10:11:25 1991
$ cc testt1.c
$ ./a.out
1234.567800 CORRECT ANSWER
$ on odin ./a.out
12dk.,-./'' <-- SOMETHING FUNNY HERE !
$ on odin cc testt1.c
$ on odin ./a.out
1.230000 <-- AND HERE TOO !
$ ./a.out
1.230000
$
Script done on Tue Jan 8 10:15:15 1991
As you can see from the above script if the program is compiled on the local
iris and run on the defective the results are strange to say the least! If the
program is compiled on the defective iris then the the answer is simply wrong,
even on the local iris.
The replacement module we got has an updated version of the PROM monitor
(3.2 revision E), our other irises are 3.1d. The operating system is 3.1d
and the C compiler version is 1.31. Our local SGI contact is a bit puzzled by
the fact that the diagnostics say everything is OK and can't explain what the
problem is. I think there may be an incompatibility between the newer board
and our older software. Or maybe it's a hardware bug which the diagnostics
can't pick up.
Can anybody help us with this problem? Is there a hardware defect or is
our software too old for the new board?
Any help is greatly appreciated,
Roberto
--
Dr. Roberto Togneri
Department of Electrical and Electronic Engineering
The University of Western Australia Phone: +61-9-380-2535
NEDLANDS WA 6009 Fax: +61-9-380-1065
Australia Email: robert@swanee.ee.uwa.oz.au