Re: M4 1.4.9b testsuite failure

[Bruno Haible]

Andreas Schwab wrote about IA-64 Pseudo-NaNs:
> It's definitely not a valid encoding.

[1] calls it an "unsupported" encoding. And you see from [2] that the
hardware treats such operands much like signalling NaNs.

> No valid operation can ever generate such an encoding.

Right, see [3].

> > While isnanl(X) = 0 may be subject to discussion,
> >   finitel(X) = 1  and
> >   printf %g X = "-5.94866e+4931"
> > are clearly inappropriate.
> 
> You are invoking undefined behaviour by useing an invalid encoding.
> There is nothing that can be validly said about this invalid encoding,
> so every answer is neither right nor wrong, but just undefined.

So it comes down to a "quality of implementation" issue. Should 'printf'
be garbage-in - garbage-out?

Why does printf("%s", NULL) print "(null)" instead of crashing with a
SIGSEGV? Because printf is often used for debugging, and a printf that
does not show what the values _really_ are is not helpful in such cases.

This same argumentation also holds for printf("%g", PseudoNaN). I'll
therefore change gnulib's isnanl module to treat PseudoNaN like NaN.

Bruno


[1] Intel IA-64 Architecture Software Developer's Manual, Volume 1:
    Application Architecture.
    Table 5-2 "Floating-Point Register Encodings"
[2] Intel IA-64 Architecture Software Developer's Manual, Volume 1:
    Application Architecture.
    Figure 5-11 "Floating-Point Exception Fault Prioritization"
[3] Intel IA-64 Architecture Software Developer's Manual, Volume 1:
    Application Architecture.
    5.1.3 "Representation of Values in Floating-Point Registers"