unnormal Intel 80-bit long doubles and isnanl

[Joseph Myers]

On Fri, 27 Nov 2020, Florian Weimer via Gcc wrote:

> The nature of these non-normal numbers is that the CPU does not produce
> them.  I think we should make sure that glibc doesn't, either, with
> obvious exceptions such as memcpy.  But beyond that, I don't know.

Exceptions probably also include the non-computational functions that just 
manipulate the sign bit (fabsl and copysignl).  And likewise the 
<complex.h> functions conjl, creall, cimagl.  (For all of these, built-in 
functions would normally be expanded inline rather than using the library 
version anyway.)

> > At the minimu ISTM that we should at least make the classification
> > consistent with gcc.
> 
> Yes, I agree.

If you want to be consistent with how the processor interprets these as 
invalid operands, that would also mean issignaling treats all these 
invalid operands as signaling NaNs.

We haven't so far tried to make <complex.h> functions do anything in 
particular with signaling NaNs (TS 18661-1 and C2x leave it 
implementation-defined how they are handled in such functions).  Arguably 
the functions other than those listed above should return (qNaN, qNaN) for 
any complex argument with at least one part sNaN (and thus for any complex 
argument with at least one part an invalid operand) rather than treating 
operands with one part sNaN and one Inf as an infinity.  (cabs should 
already do that, via its use of hypot which does handle sNaN.)

-- 
Joseph S. Myers
joseph@codesourcery.com