CVS log for src/tests/lib/libm/Makefile

Up to [cvs.NetBSD.org] / src / tests / lib / libm

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Pull up following revision(s) (requested by riastradh in ticket #963):

	tests/lib/libm/Makefile: revision 1.49
	distrib/sets/lists/tests/mi: revision 1.1315
	tests/lib/libm/t_next.c: revision 1.1
	tests/lib/libm/t_next.c: revision 1.2
	distrib/sets/lists/debug/mi: revision 1.435
	tests/lib/libm/t_next.c: revision 1.3
	tests/lib/libm/t_next.c: revision 1.4
	tests/lib/libm/t_next.c: revision 1.5
	tests/lib/libm/t_next.c: revision 1.6
	lib/libm/src/s_nexttoward.c: revision 1.3
	(all via patch)

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_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/t_next: Fix stub on VAX.
Tested building the wrong tree, oops.

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

Pull up following revision(s) (requested by riastradh in ticket #963):

	tests/lib/libm/Makefile: revision 1.49
	distrib/sets/lists/tests/mi: revision 1.1315
	tests/lib/libm/t_next.c: revision 1.1
	tests/lib/libm/t_next.c: revision 1.2
	distrib/sets/lists/debug/mi: revision 1.435
	tests/lib/libm/t_next.c: revision 1.3
	tests/lib/libm/t_next.c: revision 1.4
	tests/lib/libm/t_next.c: revision 1.5
	tests/lib/libm/t_next.c: revision 1.6
	lib/libm/src/s_nexttoward.c: revision 1.3

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_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/t_next: Fix stub on VAX.
Tested building the wrong tree, oops.

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

Pull up following revision(s) (requested by riastradh in ticket #950):

	include/math.h: revision 1.71
	include/math.h: revision 1.72
	distrib/sets/lists/debug/mi: revision 1.448
	tests/lib/libm/t_errhandling.c: revision 1.1
	tests/lib/libm/t_errhandling.c: revision 1.2
	tests/lib/libm/t_errhandling.c: revision 1.3
	distrib/sets/lists/tests/mi: revision 1.1337
	tests/lib/libm/Makefile: revision 1.50

math.h: Define FP_FAST_FMA, FP_FAST_FMAF, FP_FAST_FMAL.

These are not strictly necessary to define, really, so we haven't
exactly been nonconformant.  But they tell programs when they can
enable fast paths by using the fma(3) family of functions.

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

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>

math.h: Add missing file for math_errhandling test.
PR standards/56234: missing C99 frobs in <math.h>

Add __TEST_FENV define to fix vax build

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>

Pull up following revision(s) (requested by gdt in ticket #912):

	distrib/sets/lists/debug/mi: revision 1.449
	lib/libm/src/s_remquo.c: revision 1.3
	lib/libm/src/s_remquo.c: revision 1.4
	distrib/sets/lists/tests/mi: revision 1.1339
	tests/lib/libm/t_remquo.c: revision 1.1
	tests/lib/libm/t_remquo.c: revision 1.2
	tests/lib/libm/Makefile: revision 1.51

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.

t_remquo: Work around missing remquo(3) for vax
Part of PR port-vax/57881

libm/remquo: Fix bug where wrong quotient was returned

Fix taken from FreeBSD:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166463
  https://cgit.freebsd.org/src/commit/lib/msun/src/s_remquo.c?id=1cbd288942b08217e99bf889e0967895d53af00c

FreeBSD commit message:
  Fix a bug in remquo{,f,l}, in which the quotient didn't always have the
  correct sign when the remainder was 0.
  Fix a separate bug in remquo alone, in which the remainder and
  quotient were both off by a bit in certain cases involving subnormal
  remainders.
  The bugs affected all platforms except amd64 and i386, on which the
  routines are implemented in assembly.

(On NetBSD, this bug manifests on amd64.)

libm/remquo: Fix bug where remquo returned wrong sign of quo
ISO C requires that quo be congruent to the quotient mod 2^k and have
a particular sign.  The current code can return 0 when it should be
negative.
Because the code chooses k=31 (for the requirement of congruence
modulo 2^k), the only value available (in ILP32 or LP64) that is
negative and congruent to 0 is 0x80000000.  In the specific case of
wanting "-0", return 0x80000000.
Resolves t_remquo test failure.

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>

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

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

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.

Sync with HEAD

Add a test case for signbit.
(paranoia prior to a libm change)

Sync with HEAD, resolve a couple of conflicts

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.

Sync with HEAD

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

Sync with HEAD.  (Note that most of these changes are simply $NetBSD$
tag issues.)

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

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.

Pull up following revision(s) (requested by martin in ticket #416):
	distrib/sets/lists/comp/md.hppa: revision 1.3
	include/fenv.h: revision 1.13 via patch
	lib/libm/Makefile: revision 1.168
	lib/libm/arch/hppa/fenv.c: revisions 1.1, 1.2
	sys/arch/hppa/include/Makefile: revision 1.12
	sys/arch/hppa/include/fenv.h: revisions 1.1, 1.2
	sys/arch/hppa/include/ieeefp.h: revisions 1.5-1.7
	tests/lib/libm/Makefile: revision 1.29 via patch
fenv(3) support for hppa
--
use unsigned over uint32_t so that this file works without stdint.h
being included before hand.
fixes mknative-gcc problems, and likely others.
--
Properly separate fenv.h and ieeefp.h by moving all fenv defines
over to the former.
Now that they are decoupled, make rounding modes match the hardware bits.
--
Simplify, now that rounding mode defines match the hardware bits.

Remove stale comment about ARM fenv support.

Pull up following revision(s) (requested by gson in ticket #413):
	tests/lib/libm/Makefile: revision 1.31
	tests/lib/libm/t_fmod.c: revision 1.3
Mark the lib/libm/t_fmod test as an expected failure under QEMU,
with a reference to PR misc/44767.

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.

Rebase to HEAD as of a few days ago.

Use the same condition for HAVE_FENV

Rebase.

Add modfl(3). From FreeBSD.

sync with head.

for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.

this commit was splitted into small chunks to avoid
a limitation of cvs.  ("Protocol error: too many arguments")

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

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.

sync with head

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

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