unnormal Intel 80-bit long doubles and isnanl

Adhemerval Zanella adhemerval.zanella@linaro.org
Tue Nov 24 14:16:56 GMT 2020



On 24/11/2020 10:59, Siddhesh Poyarekar wrote:
> 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

Which is the currently take from gcc developers on this semantic change of
__builtin_isnanl? Are they considering current behavior of non classifying
the 'unnormal' as NAN the expected behavior and waiting glibc to follow
it or are they willing to align with glibc behavior? 


More information about the Libc-alpha mailing list