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 jos...@codesourcery.com