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
