Correct TEST_COMPAT conditions in totalorder compat tests.

I noticed that the totalorder compat tests mixed TEST_COMPAT
conditions using COMPAT_VER (computed as the first symbol version for
the symbol being tested) and those with a hardcoded GLIBC_2_25.

COMPAT_VER is logically correct here, so this patch changes the tests
to use it.  GLIBC_2_25 is harmless at present (even for _FloatN /
_FloatNx functions added in later glibc versions).  However, if in
future we support _Float16 functions in glibc for any existing
configuration, the test using GLIBC_2_25 would get things wrong
(wrongly think that there are compat versions of totalorderf16 and
totalordermagf16 to test).

(The actual definitions of the compat / versioned symbols for the
totalorder functions make no attempt to deal with the possibility of
libm function support for a new floating-point format, already
supported for other architectures in glibc, being added in some glibc
configuration in future, for which the only vaguely plausible case
would be if some architecture gets _Float128 support it previously
lacked; this is much like functions added after glibc 2.4 not
generally attempting to deal with compat support for long double
changing away from having the same format as double.)

Tested for x86_64, and with build-many-glibcs.py.

	* math/libm-test-compat_totalorder.inc (do_test)
	[TEST_COMPAT (libm, GLIBC_2_25, GLIBC_2_31)]: Change condition to
	[TEST_COMPAT (libm, COMPAT_VER, GLIBC_2_31)].
	* math/libm-test-compat_totalordermag.inc (do_test)
	[TEST_COMPAT (libm, GLIBC_2_25, GLIBC_2_31)]: Likewise.

0 files changed, 0 insertions, 0 deletions