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
[email protected]
