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?