Re: Broken isnan(3) and/or DQNAN on Tru64

[Bruno Haible]

Ludovic Courtès wrote:
> > And finally, what's the hexdump of that DQNAN constant?
> >
> >   #include <math.h>
> >   #include <stdio.h>
> >   int main()
> >   {
> >     printf("%04X%04X\n", DQNAN[1], DQNAN[0]);
> >     return 0;
> >   }
> 
> FFF800000000

I meant %08X instead of %04X. DQNAN therefore likely is
  FFF8000000000000
which decomposes into
  sign = 1 (irrelevant for NaNs),
  exponent = 0x7FF (highest possible value)
  mantissa = 0x8000000000000
and this is precisely the common encoding of a quiet NaN
(see <http://en.wikipedia.org/wiki/Not_a_number>).

> > What's the result for a program that uses a quiet NaN, computed
> > differently?
> >
> >   #include <math.h>
> >   double zero = 0.0;
> >   int main()
> >   {
> >     return isnan (zero / zero);
> >   };
> 
> SIGFPE with both `cc' and GCC 4.0.2.

Oh, right, division by floating-point zero and overflow exceptions lead
to SIGFPE by default on OSF/1 and Linux/Alpha. That's why we have the module
'fpieee' in gnulib.

> > What's the result when you compile it with cc?
> >   $ cc foo.c -lm
> >   $ ./a.out
> >   $ echo $?
> 
> 1
> 
> That's with "Compaq C V6.5-303 (dtk) on Compaq Tru64 UNIX V5.1B
> (Rev. 2650)".
> 
> Should we conclude that this is a GCC bug?

Possibly. And what result do you get with "gcc -mieee" ?

Bruno