tests/lib/libm: Fix various xfails related to PR lib/45362.

Writing

if (condition) {
atf_tc_expect_fail(...);
atf_tc_fail(...);
}

in order to paper over a bug in qemu renders the test nearly useless
because it will never actually fail in the event that something
unexpected is broken.

atf_tc_expect_fail only makes senes _before_ doing the test. If we
want to paper over a bug in qemu, we can do:

if (isQEMU)
atf_tc_expect_fail("qemu is broken, PR lib/...");
ATF_CHECK(condition);

That way, we are still doing the test in non-qemu circumstances, and
if the qemu bug is fixed the test will give the feedback of an
unexpected pass.

While here: Use `volatile double x = ...' as input so the compiler
doesn't optimize calls like sin(x) away at build-time, and print the
bad values with ATF_CHECK_MSG on failure in case anything goes wrong.

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.13.14; 1.13.16;
Remove expected failure and references to port-alpha/46301, now that
it is fixed.

PR misc/49356 remove unnecessary references to atf-c/config.h

The function included via this header is not used and is removed in
later versions of atf, so let us avoid it.

Remove all cargo-cult #ifndef __vax__ from the tests, that just paper
over bugs in the vax libm.

Avoid promotion in subexpressions.

Use compiler builtins instead of atf_arch and atf_machine.

The atf_arch and atf_machine configuration variables were removed from
atf-0.19 without me realizing that some tests were querying them directly.

Instead of reintroducing those variables, just rely on compiler builtins
as many other tests already do.

Should fix PR bin/48582.

branches: 1.8.2;
Remove one xfail that does not seem to fail (on alpha).

Point to PR port-alpha/46301 when failing on Alpha.

Change eps to fit within the VAX FP range.

branches: 1.5.2;
Add few basic checks.

When failing, point to the tracker PR lib/45362.

Expand the test file to contain 48 individual test cases.

PR lib/41931 should be fixed; remove expected failure.

Add a test case for PR lib/41931 reported by he@. It was verified that these
fail on NetBSD 5.99.48 amd64 but pass on amd64 Linux (glibc 2.7).