Revert to previous as requested by Rin.

As I found out the hack only applies to libc/softfloat which has issues on
m68k.

The hack should not have been applied to all m68k configurations.

Opps...Fix build.

Fix segfaults of libm tests noticable on m68k.

Also document it in doc/HACKS.

tests: Add test for remquo

This test currently fails, because remquo has bugs. (A bugfix will be
committed soon.) Test vectors derived from results from code by
Charles Karney in GeodesicLib/proj, and manually inspected.

math.h: Add math_errhandling, MATH_ERRNO, MATH_ERREXCEPT.

XXX Should maybe put a __math_errhandling in machine/math.h, but only
VAX uses MATH_ERRNO and that's not likely to change any time soon, so
this will serve for now with less churn.

PR standards/56234: missing C99 frobs in <math.h>

branches: 1.49.2;
tests/lib/libm: Test nextafter/nexttoward and variants.

The tests are fairly trivial but should work without any conditionals
about floating-point formats.

branches: 1.48.2;
Add sincos{,f,l} from FreeBSD

fix build of t_cabsl from t_cabsl.cxx

t_cabsl source is in t_cabsl.cxx not t_cabsl.cc - the latter
is what bsd.tests.mk defaults to.

This only broke after my commit of share/mk/bsd.dep.mk rev 1.85
but I don't know why it didn't cause a problem previously.

branches: 1.46.2;
Add a test case for signbit.
(paranoia prior to a libm change)

Build libm tests with -fno-builtin.

This way they test libm, not whatever the compiler does.

We should _also_ have automatic integration tests for what the
compiler does, as a separate thing.

branches: 1.44.2;
Add test case for PR lib/50646.

Make sure that cabsl (aka __c99_cabsl) is usable from C++.

Blindly add __TEST_FENV in the hope of fixing the vax build.

(So we can include fenv.h, and then not use it - we ifdef vax out
for OS-portability reasons.)

branches: 1.42.12;
define __TEST_FENV in the makefile for t_fe_round
should fix vax build (it doesn't have fenv.h)

add test for fesetround/fegetround that uses lrint (and tests it a bunch).
It doesn't fail on amd64.

Add failing test for casinh

portability fixes

add failing test for PR lib/51427
ilogb(INFINITY)=-INT_MAX, it should be INT_MAX

while here, test raised exceptions, other values.

XXX some platforms don't have exceptions

branches: 1.37.2;
Add some tests of hypot() and hypotf()

add __TEST_FENV

put have fenv stuff elsewhere.

Sync list of fenv enabled architectures again (PR 48633), this time for mips
addition.

While PR 48633 is not properly fixed, keep the additional lists of
fenv-enabled architectures in sync.

Remove stale comment about ARM fenv support.

Mark the lib/libm/t_fmod test as an expected failure under QEMU,
with a reference to PR misc/44767.

Enable fenv.h on arm again

fenv(3) support for hppa

Disabel fenv tests for arm, the implementation is incomplete.

Add a test program for basic fenv.h rounding mode/exception mask testing.

branches: 1.26.2;
Use the same condition for HAVE_FENV

Add modfl(3). From FreeBSD.

Re-enable alpha IEEE compiler options

Comment out the ieee fp flags for alpha for now - something (tm) is not
working right, see PR port-alpha/48782.

Tune COPTS for alpha

branches: 1.21.2;
Define HAVE_FENV_H on architectures that support it.
What a mess, we need a central place for this!

Initial version of fmodl from FreeBSD.
Basic test case for the fmod family.

NetBSD 6.99.26: Switch i386 and amd64 to the x87 default control word
as initial value for new processes. This means that long double
computations get the expected 63bit mantissa. Binaries tagged as
compiled for 6.99.25 and older get the old value.

Add a simple test case to ensure that double and long double computation
are working correctly.

branches: 1.18.2;
Do not re-add -mieee option on alpha, it's already set by default.

branches: 1.17.2;
Remove 't_rint' as it was committed accidentally.

As couple of checks fails on i386/qemu, reduce tolerance.

Add t_sqrt and t_cbrt.

Basic IEEE tests for the hyperbolic sine and cosine.

IEEE checks for the exponential family.

IEEE checks for the arcus functions.

Few tests for the error functions.

IEEE corner case tests for the pow(3) family (incl. PR lib/45372).

Some tests for sine, cosine, and tangent.

Merge 't_floor' to 't_ceil', and simplify.

Start systematic testing of libm(3) by first evaluating the corner cases
(NaN, +0.0, -0.0, +Inf, -Inf) for the ldexp(3) and scalbn(3) families.

Try to generate infinite values in all available floating point formats
on the FPU and check isinf() and fpclassify() results. This is
different from the libc internal consistency checks testing PR
lib/33262.

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).

Move the round(3) checks from 't_libm' to their own 't_round'
for consistency. Add -Wfloat-equal and fix comparisons.

A test case for PR lib/44057.

Add dummy test cases for ceil(3) and floor(3). It is expected that at least
one of these will fail on guest x86_64 NetBSD under Qemu. Thanks to pgoyette@
for checking the broken floor(16.999999...) = 17.

Move the only regress/lib/libm test to the new atf format

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.

tests/lib/libm/t_asin: Cite PR lib/58246.

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.3.24; 1.3.26;
Remove all cargo-cult #ifndef __vax__ from the tests, that just paper
over bugs in the vax libm.

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.1.2; 1.1.8;
IEEE checks for the arcus functions.

Handle VAX

no NaN tests for vax

Vax does not do +/- INF.

A couple of the atan tests are randomly failing.
Print the incorrect value.

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

Avoid promotion in subexpressions.

Remove header files which became unnecessary in 1.7.

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

Fix and revive test of atan_inf_neg, atan_inf_pos and atan_tan on i386.
PR port-i386/46108.
The machine epsilon 1.0e-40 is too severe and nonsense for double
because DBL_EPSILON is about 2.2e-16 . I think that 1.0e-15 is
enough good, in this case.
XXX However, test of atan_tan should be replaced for other reasons.

branches: 1.6.2;
And finally, fix boolean logic in the previous.

Fix previous: curiously enough, i386/qemu is not affected, so use the
"system(3) hack" to identify Qemu.

Point to PR port-i386/46108 when failing on i386.

Remove an escape sequence that was introduced by accident.

Fix wrong type.

branches: 1.1.2; 1.1.4; 1.1.8; 1.1.10;
IEEE checks for the arcus functions.

tests/lib/libm/t_bit: Expand and tidy.

1. Instead of calling out VAX by name, use #ifdef NAN.

2. Verify signbit works on long double on all architectures, not just
those with __HAVE_LONG_DOUBLE which means long double is _larger_
than double.

3. Minor formatting tidying.

branches: 1.1.2;
Add a test case for signbit.
(paranoia prior to a libm change)

tests/lib/libm/t_cabsl: Nix __HAVE_LONG_DOUBLE conditionals.

__HAVE_LONG_DOUBLE just means long double is different from double.
This test should always pass on all ports, even if long double is the
same as double; it doesn't test any additional precision.

branches: 1.1.2;
Add test case for PR lib/50646.

Make sure that cabsl (aka __c99_cabsl) is usable from C++.

print what went wrong.

branches: 1.1.2;
Add failing test for casinh

fix the cbrtl/powl test

cbrtl_powl is xfail only if long double has more bits than double.

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.3.24; 1.3.26;
Remove all cargo-cult #ifndef __vax__ from the tests, that just paper
over bugs in the vax libm.

Add cbrtl(3) and sqrtl(3), from FreeBSD.

branches: 1.1.2; 1.1.8;
Basic checks for the root functions.

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

Add FreeBSD's truncl and minimal testing.

Add initial version of ceill, floorl and roundl from FreeBSD.

branches: 1.7.2; 1.7.8;
Add more cases.

Fix typo.

Merge 't_floor' to 't_ceil', and simplify.

XXX: ugly hack to make these valid for vax fp.
XXX: could consolidate some of this into a common header, but i'll
leave that clean up for another time.

Do not skip the QEMU bugs but instead mark these as expected failures.

Bluntly skip the tests that fail under QEMU. XXX: system(3) is used for this?

wnCVS: ----------------------------------------------------------------------

Add dummy test cases for ceil(3) and floor(3). It is expected that at least
one of these will fail on guest x86_64 NetBSD under Qemu. Thanks to pgoyette@
for checking the broken floor(16.999999...) = 17.

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.

tests/lib/libm/t_cos: Fix comment about necessity of volatile.

tests/lib/libm/t_cos: Nix __HAVE_LONG_DOUBLE.

cosl should always be defined even on architectures where long double
is the same as double so the confusingly named __HAVE_LONG_DOUBLE is
not defined.

on i386 with FLT_EVAL_METHOD=2, the computation inside cosf was done in
binary80 arithmetic and never rounded to binary32 at the end, so it
appeared farther from the correctly rounded result in binary32 than expected.

Force binary32 using volatile float.

PR lib/54232: lib/libm/t_cos:cosf_angles regression on i386

From Riastradh.

Expand to cover long double somewhat.

The given data is for double, so use DBL_EPSILON and don't expect better
results.

Print the input to cosf on failure too.

Disable x87 implementations of sin, cos, tan.

The x87 hardware uses a bad approximation to pi for argument
reduction, and consequently yields bad answers for inputs near pi or
pi/2.

Tweak one tanf test whose doubly rounded output is a little too far
from the correct answer on the doubly rounded input.

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.4.24; 1.4.26;
Remove all cargo-cult #ifndef __vax__ from the tests, that just paper
over bugs in the vax libm.

branches: 1.3.2; 1.3.8;
Additions to PR lib/45362: the float variants cosf(3), sinf(3), and tanf(3)
do not detect NaN for positive and negative infinity on i386 (qemu).

Use fabsf(3) when appropriate.

Some tests for sine, cosine, and tangent.

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.6.24; 1.6.26;
Remove all cargo-cult #ifndef __vax__ from the tests, that just paper
over bugs in the vax libm.

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.4.2; 1.4.8;
Reduce tolerance even more.

Adjust and add some printfs.

As couple of checks fails on i386/qemu, reduce tolerance.

Basic IEEE tests for the hyperbolic sine and cosine.

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

branches: 1.1.2; 1.1.8;
Few tests for the error functions.

branches: 1.3.2; 1.3.6;
libm/t_errhandling.c: Put __TEST_FENV before any #includes.

This pattern avoids any potential problem with transitive inclusions
of fenv.h. (No change here because nothing else this file includes
transitively pulls in fenv.h, but being in the habit of doing it this
way avoids a class of problems.)

PR standards/56234: missing C99 frobs in <math.h>

Add __TEST_FENV define to fix vax build

math.h: Add missing file for math_errhandling test.

PR standards/56234: missing C99 frobs in <math.h>

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.8.14; 1.8.16;
In the exp2_values test case, provide separate expected return values
for the float case, reflecting the actual exp2f() argument value after
rounding to float precision. Fixes PR lib/49256. Thanks to Makoto
Kamada and Tetsuya Isaki for the analysis.

branches: 1.7.4;
Handle VAX

Add a lot more tests for exp2() and exp2f().
exp2f(7.7) and exp2f(8.8) seem too far from their expected values
(especially the latter).
exp2(-1023) and below are badly broken.

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

Avoid promotion in subexpressions.

Tune the epsilon about each value for exp{,f}_product.

branches: 1.2.2;
Add patch from Tetsuya Isaki in PR lib/46433.

branches: 1.1.2;
IEEE checks for the exponential family.

t_fe_round: Mark xfail on sparc64.

PR port-sparc64/59310: t_fe_round:fe_nearbyint_rint tests are failing

branches: 1.20.2;
modfl(3): Fix conversion from FreeBSD.

LDBL_MANL_SIZE is spelled EXT_FRACLBITS -- and not EXT_FRACHBITS.

PR lib/58237: modfl returns wrong answers on ld128 architectures

tests/lib/libm/t_fe_round.c: Tidy.

nextafter/nexttoward tests didn't make much sense, and are now
supplanted by t_next.

PR misc/58054

tests/lib/libm/t_fe_round: xfail for modfl uses.

PR lib/58237: modfl returns wrong answers on ld128 architectures

tests/lib/libm/t_fe_round.c: Work around likely ia64 bug in gcc.

tests/lib/libm/t_fe_round.c: Expand nearbyint/rint tests.

PR lib/58054

tests/lib/libm/t_fe_round: Fix a missed cast.

Need long long or intmax_t, not long, on LP32.

PR lib/58054

tests/lib/libm/t_fe_round: Tidy up nearbyintl, sync nearbyint test.

PR lib/58054

tests/lib/libm/t_fe_round.c: Simplify previous.

There is never any need to write casts to type T in integer constant
initializers for type T.

PR lib/58054

Use intmax_t instead of long int when trying to represent very large
integers (10^50 or so), so we don't exceed the capacity of systems where
long int is only 32 bits.

Hopefully will unbreak the i386 build, perhaps others.

tests/lib/libm/t_fe_round: Test nearbyintl.

This uses inputs that can't be distinguished with only 53 bits of
precision, so it should work in essentially all long double formats
to detect when nearbyintl is incorrectly implemented in terms of
nearbyint.

PR lib/58054

tests/lib/libm/t_fe_round: Tidy up nearbyint test.

Prompted by PR lib/58054.

don't skip nexttoward for aarch64 and mips64

fix build (missing nexttoward on mips64 and aarch64)

Add test cases for nextafter() and nexttoward(). At the moment no
corner cases are tested, and the test cases are little more than a
verification that the functions are present in the implementation.

Re-enable the test for nearbyint(), now that all ports (save vax,
which has a separate #if section here) should have nearbyint().

Revert previous as it breaks at least sparc and hpcsh builds.
nearbyint() is not included in libm on all platforms.

Add a test checking nearbyint(), using the same table as used by
the existing lrint() test.

Swap around the two last args to the check for expected fegetround(),
so the error message makes sense.

branches: 1.2.2; 1.2.8;
use labs for absolute value of long
should fix arm build

add test for fesetround/fegetround that uses lrint (and tests it a bunch).
It doesn't fail on amd64.

t_fpsetmask, t_fenv: Skip fp exception trap tests on RISC-V.

No architectural support for fp exception traps.

While here, make the macros behave a little better as C statements.

tests/lib/libm/t_fenv: Work around PR 58253.

The fetestexcept_trap test case only makes sense on FPUs that implement
exceptions.

fenv(3): Fix fetestexcept to avoid side effects on trap state.

PR port-amd64/57949

fenv(3): Add test for PR port-amd64/57949.

t_fenv: Factor checks out of switch in checkrounding.

No functional change intended, just tidies up a bit.

PR port-mips/57680

XXX pullup-10

t_fenv: Use volatile intermediate to force rounding to double.

See comment for details about why this is necessary.

Should fix these tests on i386 (and perhaps m68k too).

PR port-mips/57680

XXX pullup-10

t_fenv: Improve diagnostics when rounding mode tests fail.

Print the correct input, and print the rounding mode for clarity so
you don't have to cross-reference it by line number.

PR port-mips/57680

XXX pullup-10

t_fenv: Add #pragma STDC FENV_ACCESS ON and verify FLT_RADIX is 2.

Except gcc doesn't implement this pragma, so make it conditional.

And clang only supports it on some architectures, so just leave it
out for now with a comment about why.

PR port-mips/57680

XXX pullup-10

t_fenv: Verify rounding mode takes effect.

At least for addition operations, anyway.

Somewhat redundant with the test t_fe_round added by maya@ but this
gives two minimal pairs to easily diagnose exactly what the rounding
mode is when the wrong one was selected.

PR port-mips/57680

XXX pullup-10

t_fenv: Check FLT_ROUNDS whenever we touch the rounding mode.

PR port-mips/57680

XXX pullup-10

t_fenv: Print wrong values if tests fail.

XXX pullup-10

branches: 1.6.2; 1.6.10;
Fix typo in 'exceptions'

Clean up terminology: modern arm CPUs do properly implement IEEE 754
floating point exceptions - but some (actually all currently know ones)
do not implement sending traps when these exceptions are raised.

Pointed out by Peter Maydell.

There are aarch64 Cortex cpus that do not trap on some floating point
exceptions - so apply the arm handling for aarch64 as well.

branches: 1.3.8; 1.3.14; 1.3.16;
put have fenv stuff elsewhere.

Skip rounding mode tests on ARM FPUs that do not allow configuration of them.

Add a test program for basic fenv.h rounding mode/exception mask testing.

Merge 't_floor' to 't_ceil', and simplify.

Remove some cruft that is no longer needed.

Remove Xfails that are related to the infamous qemu/amd64 floating point
bugs. It appears to be quite difficult to identify the exact Qemu version
and setup. These do not fail on the TNF's qemu/amd64 setup, which can be
taken as a reference point for expected failures.

Improve the QEMU/amd64 detection.

XXX: ugly hack to make these valid for vax fp.
XXX: could consolidate some of this into a common header, but i'll
leave that clean up for another time.

Do not skip the QEMU bugs but instead mark these as expected failures.

Bluntly skip the tests that fail under QEMU. XXX: system(3) is used for this?

wnCVS: ----------------------------------------------------------------------

Even these naive test cases caught one (QEMU?) bug; comment PR # 44767.

Add dummy test cases for ceil(3) and floor(3). It is expected that at least
one of these will fail on guest x86_64 NetBSD under Qemu. Thanks to pgoyette@
for checking the broken floor(16.999999...) = 17.

Only expect the fmod test case to fail when using qemu's TCG CPU emulation,
and not under hardware virtualization such as qemu -accel nvmm.

Mark the lib/libm/t_fmod test as an expected failure under QEMU,
with a reference to PR misc/44767.

branches: 1.2.4; 1.2.6; 1.2.8;
Avoid promotion in subexpressions.

Initial version of fmodl from FreeBSD.
Basic test case for the fmod family.

tests: Use `#if __*_HAS_DENORM__', not `#ifdef __*_HAS_DENORM__'.

The compiler defines this to zero on, e.g., VAX.

PR port-vax/59261: t_fpclassify tests are failing

branches: 1.8.2;
tests/t_hypot: actually add nan test

t_hypot: Use an ld80 test case that actually fits in ld80.

Also add comments explaining how I generated these test cases.

(No autoconf back doors hidden in these magic numbers, I promise! No
pythagoreans were harmed in the production of these tests either.)

tests/lib/libm/t_hypot: Check inf/nan cases too.

hypotl(3): Fix includes and macros.

1. Need <math.h> for __HAVE_LONG_DOUBLE.
2. Need <machine/ieee.h> for struct ieee_ext_u &c.
3. EXT_FRACLBITS, not LDBL_MANL_SIZE.

PR lib/58245: hypotl is broken on ld128 ports

tests/lib/libm/t_hypot: More trivial tests.

Check both signs of zero.

tests/lib/libm/t_hypot: Expand substantially.

PR lib/58245: hypotl is broken on ld128 ports

Reference PRs consistently.

Add some tests of hypot() and hypotf()

t_ilogb: Nix spurious line break in ATF_CHECK_MSG.

tests/lib/libm/t_ilogb: Expand and tidy.

1. Instead of calling out VAX by name, use #ifdef NAN and
isinf(INFINITY). (VAX defines INFINITY even though it's not an
infinity, not sure if there's a better compile-time test.)

2. Verify ilogbl works on long double on all architectures, not just
those with __HAVE_LONG_DOUBLE which means long double is _larger_
than double.

for consistency, print the statement that is true in the error case.
also add missing closing paren

Test for FE_INVALID in a way that works for powerpc too.

powerpc seems to return FE_INVALID | FE_VXSOFT rather than just FE_INVALID.
XXX need extra careful reading of standards

branches: 1.7.12;
PR/51837: Ngie Cooper: add limits.h for INT_MAX

branches: 1.6.2;
forgot to protect an ilogbl

fix test; clearing the exception does not return the old exception bitmask.

fix long double

portability fixes

Mistakes were made, compare correct values now.

add failing test for PR lib/51427
ilogb(INFINITY)=-INT_MAX, it should be INT_MAX

while here, test raised exceptions, other values.

XXX some platforms don't have exceptions

tests/lib/libm/t_infinity: Remove broken long double conditional.

LDBL_MAX is always defined, so this branch is dead. (If LDBL_MAX is
not defined, that's a bug in the architecture's float.h, not a reason
to skip a test.)

Remove expected failures that no longer fail (probably due a Qemu update).

branches: 1.5.2; 1.5.8;
Remove the amd64-part from the Qemu checks. The following tests fail also on
i386/qemu: 'strtold_inf', 'strtold_nan', and 'infinity_long_double'. It seems
that more than anything else, these are dependent on the used Qemu version.

Improve the QEMU/amd64 detection.

Add <stdlib.h> for system(3).

Mark the following tests as expected failures on qemu/amd64: 'strtod_inf',
'strtod_round', and 'infinity_long_double'. None of these fail on any known
native host. Use the tracker PR misc/44767 as the reference point.

Try to generate infinite values in all available floating point formats
on the FPU and check isinf() and fpclassify() results. This is
different from the libc internal consistency checks testing PR
lib/33262.

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.16.12; 1.16.14;
Add a failing case for t_ldexp

ldexp(2.0, INT_MAX) should be HUGE_VAL, not 0

don't skip the entire test iteration if exp2=SKIP, only the second
application of the function

this doesn't introduce new failures on amd64

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.

Avoid double constants out of range

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

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.10.2; 1.10.8;
Move duplicate ldexp(3) test out from the tests/libc.

Reduce the powers.

Adjust to see where this fails on i386/qemu.

Fix bug/oversight.

Use fabsf(3) when appropriate.

Test ldexp(x, n) == x * exp2(n) && ldexpf(x, n) == x * exp2f(n).

Improve the metadata descriptions.

Happiness of VAX implies ugliness of the code.

Add more assertions.

Start systematic testing of libm(3) by first evaluating the corner cases
(NaN, +0.0, -0.0, +Inf, -Inf) for the ldexp(3) and scalbn(3) families.

Move the round(3) checks from 't_libm' to their own 't_round'
for consistency. Add -Wfloat-equal and fix comparisons.

Move the only regress/lib/libm test to the new atf format

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.6.4; 1.6.8; 1.6.28; 1.6.30;
Consistently use long double.

Print the result as a 'long double' - on i386 a return value that
should be infinity might just be too large for 'double' and won't
get converted until it has to be saved to memory.

Check that the result isn't equaly to the expected value before checking
the absolute size of the error term.
If the expected result is +/-infinity it should compare equal, but the
result of the subtract may not be zero.
Also print the result and error values in fp hex to make it easier to
see how may lsb bits are incorrect.

Vax does not do +/- INF.

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.

tests/lib/libm/t_log.c: Record xfail for PR port-i386/58434.

PR port-i386/58434: single-float functions return surprisingly much
precision

libm: Fix order of significand words in EXTRACT_LDBL128_WORDS.

PR lib/58337

tests/lib/libm/t_log: Expand some more.

- Test nontrivial bit patterns for log, log2, log10, log1p.
- Print long double with %.34g, not %.17g.
- Sprinkle xfail for the ld128 code.

PR lib/58337: logl() crashes on arm64

tests/lib/libm/t_log.c: Expand to handle many more cases.

Also make this much more concise.

Prompted by PR lib/58337: logl() crashes on arm64

branches: 1.15.2;
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).

modfl(3): Fix conversion from FreeBSD.

LDBL_MANL_SIZE is spelled EXT_FRACLBITS -- and not EXT_FRACHBITS.

PR lib/58237: modfl returns wrong answers on ld128 architectures

tests/lib/libm/t_modf: Mark modfl xfail on ld128.

PR lib/58237: modfl returns wrong answers on ld128 architectures

tests/lib/libm/t_modf: Use isinf(INFINITY) to detect inf support.

Apparently VAX defines the INFINITY macro even though it's not
actually an infinity and isinf returns zero for it.

tests/lib/libm/t_modf: Check sign of modf on infinities too.

Normally I don't like CHECK(A && B) and favour CHECK(A); CHECK(B)
instead, so you can see which one failed, but in this case the inputs
are displayed anyway so we don't lose anything unless the
floating-point printer is broken.

tests/lib/libm/t_modf.c: Expand modf/modff/modfl tests.

1. Exercise more edge cases around the largest exponent that can
represent non-integers.

2. - Verify modf can handle all cases modff can.
- Veriy modf can handle some cases modff can't.
- Verify modfl can handle all cases modf or modff can.
- If long double isn't just double, verify modfl can handle some
cases modf and modff can't.

3. Check infinities and NaN.

4. Verify oddness, i.e., modf(-x) = -modf(x).

5. Display more useful diagnostics in case any of this goes wrong.

branches: 1.1.2; 1.1.6;
Add modfl(3). From FreeBSD.

tests: Use `#if __*_HAS_DENORM__', not `#ifdef __*_HAS_DENORM__'.

The compiler defines this to zero on, e.g., VAX.

PR port-vax/59261: t_fpclassify tests are failing

branches: 1.7.2; 1.7.4; 1.7.6;
tests/lib/libm/t_next: Disable a test if long double is double.

This test, to verify nexttoward(x, x*(1 - LDBL_EPSILON/2)) moves in
the direction of x*(1 - LDBL_EPSILON/2), only makes sense if long
double has more precision than double -- the point of the exercise is
to verify that nexttoward moves even if the direction parameter can't
be rounded to double. But if long double is just double, this test
makes no sense.

nexttoward(3): Fix high-word test on small positive subnormals.

By this point in the logic, x can't be zero, so it's either positive
or negative.

The high word hx, however, can be zero, when x is a small positive
subnormal. This means x is a small positive subnormal, so if x > y
we are computing nextDown, and if x < y we are computing nextUp.

hx is a (signed 32-bit) integer, not a double floating-point number,
so it's a little silly to compare hx > 0.0. But that on its own
isn't enough to trigger the bug because all signed 32-bit integers
can be represented by double on all NetBSD architectures.

PR lib/58236

tests/lib/libm/t_next: nexttoward works if it's just nextafter.

It's broken on platforms where long double and double aren't the same
and nexttoward isn't an alias for nextafter.

tests/lib/libm/t_next: Expand substantially.

This covers many more potential problem areas -- and includes a new
xfail test for PR lib/58236: nexttoward(3) is broken on subnormals.

tests/lib/libm/t_next: Fix stub on VAX.

Tested building the wrong tree, oops.

tests/lib/libm/t_next: Disable this test on VAX.

But leave a replacement xfail test that fails unconditionally, to
leave a reminder in the tests of PR 57881: vax libm is missing
various symbols.

tests/lib/libm: Test nextafter/nexttoward and variants.

The tests are fairly trivial but should work without any conditionals
about floating-point formats.

tests/lib/libm/t_pow: Revamp.

1. Avoid the broken idiom

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

2. Sprinkle volatile and ATF_CHECK_MSG.

use isinf instead of isinff. this doesn't introduce a functional change -
isinf works for float as well, and is more portable.

from Ngie Cooper in PR bin/51838

branches: 1.4.2; 1.4.4;
Clear the XFAIL from PR 45391.

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

branches: 1.2.2; 1.2.8;
More bugs in pow(3); cases for PR port-amd64/45391.

IEEE corner case tests for the pow(3) family (incl. PR lib/45372).

tests/lib/libm/t_precision: Nix __HAVE_LONG_DOUBLE conditionals.

long double and LDBL_EPSILON work even on architectures where long
double is the same as double, i.e., where the confusingly named
__HAVE_LONG_DOUBLE is not defined.

do the long double tests if we have long double.

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.

branches: 1.1.4; 1.1.8;
NetBSD 6.99.26: Switch i386 and amd64 to the x87 default control word
as initial value for new processes. This means that long double
computations get the expected 63bit mantissa. Binaries tagged as
compiled for 6.99.25 and older get the old value.

Add a simple test case to ensure that double and long double computation
are working correctly.

branches: 1.2.2; 1.2.6;
t_remquo: Work around missing remquo(3) for vax

Part of PR port-vax/57881

tests: Add test for remquo

This test currently fails, because remquo has bugs. (A bugfix will be
committed soon.) Test vectors derived from results from code by
Charles Karney in GeodesicLib/proj, and manually inspected.

fix various typos in comments.

Fix verb form.

Use a global double to stop GCC from optimizing the test away
Better diagnostic messages
More familiar test for 'even number'

Add a short case for the alpha test failure

Now I see it's down to the choice of -mfp-trap-mode (n works, su/sui/u don't)

use PRIu64 to print uint64_t, don't print sizeof

fixes build. sorry, built tested an older version for 32bit.

Add test case for alpha's MPFR config test failure
This assert fires with -mieee, but not without it.

Add initial version of ceill, floorl and roundl from FreeBSD.

branches: 1.3.2; 1.3.8;
Assign missing copyright to TNF.

XXX: If these originated from you, please modify accordingly.

XXX: ugly hack to make these valid for vax fp.
XXX: could consolidate some of this into a common header, but i'll
leave that clean up for another time.

Move the round(3) checks from 't_libm' to their own 't_round'
for consistency. Add -Wfloat-equal and fix comparisons.

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.

tests/lib/libm/t_scalbn: Nix __HAVE_LONG_DOUBLE conditionals.

If long double is the same as double, i.e., __HAVE_LONG_DOUBLE is
undefined, these tests should still pass, since they don't rely on
extra precision beyond double.

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.15.2;
Test and clear exception around scalbn calls.
Second part of PR bin/51834.

ifdef out vax to avoid netbsd-specific macros.

branches: 1.14.12;
also terminate 2 other statements properly

terminate the statement properly

PR/51839: Ngie Cooper: reset errno to 0 before calling scalbn*

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

Backout previous - real fix for vax libm upcoming.

vaxinate the new tests.

Add a few test cases to test "ordinary" values with the various scalbn
variants. While there, make some spuriously failing tests print out the
broken values on failure.

branches: 1.7.2; 1.7.8;
Improve metadata once again.

Test that scalbn(x) == ldexp(2) whenever FLT_RADIX == 2 (like it should be
on all systems except exotic relics such as IBM 360).

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

Improve the metadata descriptions.

Happiness of VAX implies ugliness of the code.

Add more assertions.

Start systematic testing of libm(3) by first evaluating the corner cases
(NaN, +0.0, -0.0, +Inf, -Inf) for the ldexp(3) and scalbn(3) families.

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.

Print result of function we tested (sinf),
not of function we didn't test (sin).

no need to print 17 digits for a float.

from Riastradh.

Disable x87 implementations of sin, cos, tan.

The x87 hardware uses a bad approximation to pi for argument
reduction, and consequently yields bad answers for inputs near pi or
pi/2.

Tweak one tanf test whose doubly rounded output is a little too far
from the correct answer on the doubly rounded input.

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.4.24; 1.4.26;
Remove all cargo-cult #ifndef __vax__ from the tests, that just paper
over bugs in the vax libm.

branches: 1.3.2; 1.3.8;
Additions to PR lib/45362: the float variants cosf(3), sinf(3), and tanf(3)
do not detect NaN for positive and negative infinity on i386 (qemu).

Use fabsf(3) when appropriate.

Some tests for sine, cosine, and tangent.

tests/lib/libm/t_sincos: Nix __HAVE_LONG_DOUBLE conditionals.

sincosl is supposed to be there even if long double is double, as is
the case when __HAVE_LONG_DOUBLE is undefined.

Add sincos{,f,l} from FreeBSD

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.6.24; 1.6.26;
Remove all cargo-cult #ifndef __vax__ from the tests, that just paper
over bugs in the vax libm.

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.4.2; 1.4.8;
Reduce tolerance even more.

Adjust and add some printfs.

As couple of checks fails on i386/qemu, reduce tolerance.

Basic IEEE tests for the hyperbolic sine and cosine.

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.7.24; 1.7.26;
Avoid double constants out of range

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

Adjust expected epsilon for sqrtl <-> powl comparisions for defects in
powl (which actually is pow for now)

Add cbrtl(3) and sqrtl(3), from FreeBSD.

branches: 1.3.6;
Fix wrong error failure message.

The compiler is allowed to use intermediate higher precision for float
arithmetic, which may cause differences smaller than float precision
but still much larger than eps = 1e-30.
Forcing intermediate results to volatile variables removes the excess
precision.

branches: 1.1.2;
Basic checks for the root functions.

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.

Disable x87 implementations of sin, cos, tan.

The x87 hardware uses a bad approximation to pi for argument
reduction, and consequently yields bad answers for inputs near pi or
pi/2.

Tweak one tanf test whose doubly rounded output is a little too far
from the correct answer on the doubly rounded input.

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.5.24; 1.5.26;
Remove all cargo-cult #ifndef __vax__ from the tests, that just paper
over bugs in the vax libm.

branches: 1.4.2; 1.4.8;
#ifdef on __vax__ one more place, to avoid reference to tanf() for vax.

Additions to PR lib/45362: the float variants cosf(3), sinf(3), and tanf(3)
do not detect NaN for positive and negative infinity on i386 (qemu).

Use fabsf(3) when appropriate.

Some tests for sine, cosine, and tangent.

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

branches: 1.6.2; 1.6.8;
Improve the metadata descriptions.

Happiness of VAX implies ugliness of the code.

Be more systematic and coarse-grained.

When failing, point to PR lib/44057 and the discussion therein about the
relevant compiler bug.

Fix build failure on VAX.

A test case for PR lib/44057.