unnormal Intel 80-bit long doubles and isnanl

[Siddhesh Poyarekar]

On 11/24/20 7:11 PM, Szabolcs Nagy wrote:
> ideally fpclassify (and other classification macros) would
> handle all representations.
> 
> architecturally invalid or trap representations can be a
> non-standard class but i think classifying them as FP_NAN
> would break the least amount of code.

That's my impression too.

>> glibc evaluates the bit pattern of the 80-bit long double and in the
>> process, ignores the integer bit, i.e. bit 63.  As a result, it considers
>> the unnormal number as a valid long double and isnanl returns 0.
> 
> i think m68k and x86 are different here.
> 
>>
>> gcc on the other hand, simply uses the number in a floating point comparison
>> and uses the parity flag (which indicates an unordered compare, signalling a
>> NaN) to decide if the number is a NaN.  The unnormal numbers behave like
>> NaNs in this respect, in that they set the parity flag and with
>> -fsignalling-nans, would result in an invalid-operation exception.  As a
>> result, __builtin_isnanl returns 1 for an unnormal number.
> 
> compiling isnanl to a quiet fp compare is wrong with
> -fsignalling-nans: classification is not supposed to
> signal exceptions for snan.

I agree, but I think that issue with __builtin_isnanl is orthogonal to 
the question about unnormals.  Once that is fixed in gcc, we could 
actually use __builtin_isnanl all the time in glibc for isnanl.

Siddhesh