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