unnormal Intel 80-bit long doubles and isnanl
Joseph Myers
joseph@codesourcery.com
Wed Nov 25 19:27:46 GMT 2020
On Wed, 25 Nov 2020, Siddhesh Poyarekar wrote:
> Would you agree to treating unnormals as NaNs and consequently have glibc
> provide that guarantee in the library instead of either declaring it undefined
> or maintaining the status quo, i.e. keeping it unspecified?
I think it would be a pain to maintain test coverage for unnormals (and
presumably all the other kinds of unsupported operands, and you'd need to
work out what semantics you want for pseudo-denormals as well since those
are the one kind of such representation the processor doesn't raise
"invalid" for) for all the functions with floating-point arguments - and
claiming to handle those consistently requires having such test coverage
(there are only a few tests for such format-specific representations in
sysdeps/ieee754/ldbl-96 at present).
But maybe you could set up some mechanism by which, when gen-libm-test.py
processes a test using snan_value or snan_value_ld (but not
snan_value_pl), and the relevant format is one of the format variants that
has these representations, it automatically generates tests for all those
variants (that the processor raises "invalid" for when handling as
operands, i.e. treats much like sNaN). I'm not sure if it's actually
possible to generate a static initializer for a long double value with one
of those representations, or only for a union containing a long double
where another member is initialized; if a union type needs to be used in
the tables of test inputs, that further complicates things.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list