Matthew Fortune <matthew.fort...@imgtec.com> writes:
> Joseph Myers <jos...@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).
IMO that's an argument in favour of allowing MSA code to be compiled
for the legacy encoding. That way no mixing occurs and the ELF flag
accurately indicates which NaN encoding was used by the compiler.
Anything that wanted to detect mismatches between the "compiled-for"
encoding and the run-time encoding would have all the info it needs.
Another advantage is that it requires no code changes at all. :-)
It's just a case of not adding new code.
Thanks,
Richard
