Re: [PATCH v3 2/2] x86 long double: Add tests for pseudo normal numbers

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 24 Dec 2020, Siddhesh Poyarekar via Libc-alpha wrote:

> Add some tests for fpclassify, isnan, isinf and issignaling.

This looks like these tests get duplicated for every floating-point type 
for which they are run.  They should only be run for long double and 
_Float64x; when the libm tests are run for other floating-point types 
(choices of FLOAT), these new tests should be compiled out.

Note that "f" in the test macro names means FLOAT, but these tests seem 
always to test long double, indpendent of the choice of FLOAT, not FLOAT.  
(The second argument of nexttoward is the only case where it's *correct* 
for a math/ test to use long double independent of FLOAT.)

Properly testing _Float64x (i.e. with that as the argument type to the 
macro, not long double, when FLOAT is _Float64x) may need further changes; 
either not using the math_ldbl.h unions but a local union with FLOAT, or 
casting the argument to type FLOAT.

> +/* For pseudo-normal number tests.  */
> +#if HANDLE_PSEUDO_NUMBERS
> +# include <math_ldbl.h>
> +#define pseudo_inf { .parts = { 0x00000000, 0x00000000, 0x7fff }}
> +#define pseudo_zero { .parts = { 0x00000000, 0x00000000, 0x0100 }}
> +#define pseudo_qnan { .parts = { 0x00000001, 0x00000000, 0x7fff }}
> +#define pseudo_snan { .parts = { 0x00000001, 0x40000000, 0x7fff }}
> +#define pseudo_unnormal { .parts = { 0x00000001, 0x40000000, 0x0100 }}

I think the right condition here (and everywhere in this patch) is 
TEST_COND_intel96: a condition on the format for which the tests are being 
run rather than on how glibc is built.  The tests are both specific to 
rules for that format about which encodings are valid (the high bit of the 
significand is unspecified for NaNs and infinities for m68k), and, in the 
form in which they're written here, also specific to little-endian, since 
you're relying on the ordering of initializer elements rather than using 
designated initializers, so wouldn't work on m68k for that reason as well.

If you need to avoid these tests for ia64 because of different rules on 
such encodings for ia64, some other condition might then be used *inside* 
a TEST_COND_intel96 condition.

-- 
Joseph S. Myers
joseph@codesourcery.com