Re: Built-in testing for signaling nan?

["N.M. Maclaren" <nmm1 at cam dot ac dot uk>]

On Nov 7 2013, FX wrote:
> > Given how murky signaling NaNs are in practice, I think it's worth
> > asking: why do you want to know?
>
> Because I am writing an implementation of the IEEE support modules in GNU 
> Fortran, which are part of the Fortran 2003 standard. And the standard 
> provides for a procedure (IEEE_CLASS) to distinguish between 
> IEEE_SIGNALING_NAN and IEEE_QUIET_NAN. It doesn't explicitly state that 
> supporting sNaN is required, so I can also just not return it.

Yes.  There is also the issue that the Fortran community (which gfortran
follows) takes portability very seriously indeed, both over a very wide
range of systems and over long periods of time.  Simply saying "if your
system doesn't fit into one of these two categories, you can't have any
of this facility" is not regarded as reasonable.  Those weren't/aren't
the only ways NaNs could be provided.

Unfortunately, that is probably the best that can be done for a reasonable
amount of effort.  I.e. to pass the buck back to base gcc, and put up with
its restrictive view of the universe of 'IEEE 754 support'.  Because this
area is such a complete mess, most people interested in extreme portability
will continue to ignore all of the IEEE 754 facilities, even in Fortran
(which gets them at least part-right).

I can't say that I am entirely happy with your effort, because the problem
is that having the procedures available will encourage people to trust
the IEEE features, and the real problems are in the optimisation and code
generation.  In particular, there will be pressure to remove optimisations
and not add new ones because of perceived semantic conflicts - we have
seen this very badly in the C world.


Regards,
Nick Maclaren.