Fix up libm tests.

- Fix up last few digits of a lot of known-answer tests.

Confirmed with GNU mpfr to 200 bits of precision and cross-checked
with whatever libm Ubuntu ships with.

- Test relative error, not absolute error.

- Set bounds in terms of *_EPSILON, not magic numbers.

*_EPSILON is twice the largest relative error of a correctly
rounded operation, and equal to the largest relative error of an
operation with up to 1ulp error.

Most of the operations we're testing are not correctly rounded, but
they ought to be no more than 1ulp away. For the few cases where
that's not a priori clear (like comparing cbrt and pow(x, 1/3)),
use twice *_EPSILON to allow some leeway.

- Write the success condition positively as error <= eps.

This comes out false if the result is a NaN, meaning failure. In
contrast, if we write error > eps for the _failure_ condition, then
if the result is a NaN, it will also come out false, but meaning
success, which is not what we want.

- Fix the trigonometric test cases near bad spots.

sin(pi - d) for nonzero d is not zero; it is d + O(d^3). pi is not
a floating-point number, so these results should be approximately
the nonzero error of our approximation to pi. Likewise with
cos(pi/2 - d) and tan(pi + d).

(Yes, I know the sin _function_ is ill-conditioned near pi so you
shouldn't pass approximate inputs near there, but that's separate
from whether a sin _implementation_ gives an answer that is wrong
by quintillions of ulps.)

Since on x86 (i386 and amd64 alike) we currently use x87 hardware
trigonometric instructions, which are bad, these are marked xfail
on x86 for now until we switch to software implementations (coming
soon to a repository near you).

- Use %.8g, %.17g, %.35g to print float, double, long double in failures.

This should be enough to identify the problematic outputs and/or
reproduce the computation, even if long double is binary128 with
115 bits of precision.

If there are any new libm test failures after this, tell me what
architecture you're on and send me the atf output and I'll try to
figure it out.

branches: 1.10.24; 1.10.26;
Fix some typos.
Make the infinity and nan constants 'double' not 'long double'.

Move the #defines that simplified the test definitions and checks
into a separate header than can be used by the other libm tests.
Make the subtest index 'unsigned int' so that simple constants (eg 0)
print correctly.

Remove the print of the rounding mode.
It was added in case it was non-zero - which it isn't.
It still isn't clear why acos(-1) gives the wrong result on some amd64
systems.

Fix build for platforms w/o fenv.h.
Remove some bogus #ifdef __vax__ (and add a few, hopefully non-bogus,
new ones).

Include the subtest number in any error output.
Also temporarily print the rounding mode.
I think that acos(-1) is ending up with the wrong sign because the test
is being run with 'round towards -ve infinity' set.
I think it getting set somewhere and causing this test to fail.
The acos() code probably needs fixing - it shouldn't depend on the
round mode like this. But first I want to know if this if the error.

Some of the acos() tests seem to fail on some systems.
Sorting out why isn't helped by the tests not reporting the erronous value.
Change the 'boilerplate' pattern used so that all the values are output.
Reduce the amount of faffy red tape as well.
Some of these reductions could be shared with other libm tests, but for
the moment they are defined in this file.
All these tests pass on my amd64 system, and when I run amd64 qemu.

Use a pre-calculated value as expected result, instead of
comparing it in a mathematical formula.
PR lib/46434 (and see also 46433).

branches: 1.3.2;
If one of the tests with eps fails, print the failing eps.

branches: 1.2.2;
Reduce tolerance to see whether still acosf(cosf(x)) != x on i386/qemu.

IEEE checks for the arcus functions.