I've done some investigation into failures of test-frexpl, test-isnanl, and
test-vasnprintf-posix on Irix 6.5.
The Irix 6.5 cc, on 0.0L/0.0L, produces:
(gdb) p sizeof x
$1 = 16
(gdb) x/4x &x
0x7ffb7ea0: 0x7ff7ffff 0xffffffff 0x00000000 0x00000000
(gdb) p x
$2 = nan(0x7ffffffffffff)
but gcc 3.4.3 on the same platform produces:
(gdb) x/4x &x
0x7ffb7e80: 0x7ff00000 0x00000000 0x00000000 0x00000000
(gdb) p x
$1 = 0
The following program discovers a way to coerce long double NaN even with gcc:
-------
#include <stdio.h>
#include <math.h>
int main()
{
double w = 0.0 / 0.0;
long double ww = w;
long double x = 0.0L / 0.0L;
long double zero = 0.0L;
long double y = zero / zero;
long double inf = 1.0L / 0.0L;
long double z = inf - inf;
printf("%d %d %d %d %d\n", isnan (w), isnan (ww),
isnan (x), isnan (y), isnan (z));
return 0;
}
------
$ cc -o foo foo.c
$ ./foo
1 1 1 1 1
$ gcc -o foo foo.c
$ ./foo
1 1 0 0 0
Although both compilers made ww a NaN, gcc still doesn't come up with bit-
identical results. Oh well.
cc:
(gdb) x/4x &ww
0x7ffb7e40: 0x7ff7ffff 0xffffffff 0x00000000 0x00000000
gcc:
(gdb) x/4x &ww
0x7ffb7e30: 0x7fffffff 0xfffffffc 0x00000000 0x00000000
(gdb) p ww
$2 = nan(0xffffffffffffc)
So, I am working on a patch that looks for all instances of 0.0L / 0.0L in the
testsuite, and replacing them with a call to NaNl() from tests/nan.h; at the
same time, beefing up that macro to use type conversion from double to long
double on Irix as the only known way to guarantee a NaN.
--
Eric Blake
