RE: [RFC, MIPS] Relax NaN rules

["Joseph S. Myers" <joseph at codesourcery dot com>]

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".

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.)

-- 
Joseph S. Myers
joseph@codesourcery.com