CVS log for src/lib/libm/src/s_nexttoward.c

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

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

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

Rebase to HEAD as of a few days ago.

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

Add support for archs with LDBL_IMPLICIT_NBIT

commit long double SoC code from Stathis Kamperis