RE: [RFC, MIPS] Relax NaN rules

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Joseph Myers <joseph@codesourcery.com> writes:
> On Tue, 25 Mar 2014, Rich Fuhler wrote:
> 
> > Hi Richard, we talked about (a.) originally - it was the design of the
> > libraries. Joseph, as I recollect, you raised language issues with
> > requirements for compile-time constant values for NaNs. Would you
> > accept a non-constant NaN implementation in glibc? Basically, I would
> > envision
> > __builtin_nan("") to be 0.0/0.0. Probably not a problem for C++ or
> > most code.
> 
> 0.0/0.0 is not correct for NaN when used outside static initializers,
> because it raises INVALID when doing the division at runtime.  Raising
> INVALID when not wanted is exactly the same problem you'll get if you
> mix code that uses different NaN conventions but doesn't care about
> signaling NaNs per se, so 0.0/0.0 doesn't help there.  And in static
> initializers it doesn't help at all because then it will get folded to
> the same NaN bit-pattern as __builtin_nan("").  So you don't gain
> anything from such a change.  Literally disallowing NaN static
> initializers brings you into the realm of weird non-IEEE floating-point
> configurations we should not be adding support for in glibc.
> 
> If you want to use code built for the new NaN convention without
> requiring libraries built for that convention (and are willing to risk
> random INVALID exceptions as NaNs get passed between the conventions),
> as already stated the obvious approach is a command-line option or
> combination of options meaning "build code for this convention, but use
> the other convention when marking object files and choosing libraries
> and a dynamic linker".

Can you envisage any way of us raising a warning/error if INVALID 
exceptions get enabled in this hybrid NaN world? I believe that is the 
only major problem area with mixing NaNs. I.e. It should be possible to 
introduce a magic symbol if LD merged opposing NaN modules and have 
fesetexcept check for it but I can't think up a way to indicate to 
fesetexcept if LDSO linked opposing NaN modules (I'm not sufficiently 
experienced with dynamic linkers to know what is possible though).

> What's the status of the Linux kernel support for the new NaN
> convention, incidentally?  glibc built for the new convention sets
> arch_minimum_kernel=10.0.0 until the support is in kernel.org and so the
> value can be set to the actual first kernel with the support....
> (arch_minimum_kernel=10.0.0 may be used in future for any other cases
> where glibc support for a port or port variant gets in before the kernel
> support.)

Kernel support is queued up against a significant number of other features 
that are being actively worked on. I do know that it is on the list just 
not necessarily close to the top just yet. Given the chicken and egg 
situation we have in terms of enabling nan2008 glibc from a specific 
kernel version then this of course has to be done before any glibc with 
nan2008 support can even be considered by a distribution.

Regards,
Matthew