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