don't exist as compat functions in libc.
current list of new platforms: powerpc64.
from dennis.c.ferguson@gmail.com in PR#43042. idea to not put compat
functions into new platforms from drochner@netbsd.
made to fail. Specifically, change
.ifdef(SYMBOL) -> .ifdef SYMBOL or .if defined(SYMBOL),
and corresponding for .ifndef.
Also correct one error in lib/libm/Makefile (.ifdef (${MKCOMPLEX} != "no")?!?).
eg expf(-Inf) which was Nan previously
(We could avoid touching the i387 on amd64 in these cases, but we'd
need to bypass the ABI abstraction macros, so leave it the old way
for now.)
-replace ARG_DOUBLE_ONE_HALF by _MSW/_LSW because this reflects the
intention and also matches the terms used in C code,
also make the code where the fpcw overwrites the argument a bit
self-documenting
(this abstraction sucks because it forces to write inefficient code)
6.11.5 Storage-class specifiers
[#1] The placement of a storage-class specifier other than
at the beginning of the declaration specifiers in a
declaration is an obsolescent feature.
and gcc -Wextra warns about this, so s/const static/static const/
hypotf() functions for vax. Play the namespace and weak alias game for
functions used internally by the complex functions. Should fix the vax
build of libm.
roff source from the Linux documentation project.
Modifications before import:
-added NetBSD RCS ID
-removed Linux PROLOG and declarations with "long double"
-ran the "deshallify" script as required by The Open Group
Split out complex related things into an own Makefile fragment.
Thanks to hubertf for directions.
leads to loss of precision, leading to rounding into the wrong direction
for the case 0.5-epsilon. use floor() instead.
This also fixes a wrong sign of zero returned with non-default rounding
directions.
Most complex function implementations are from the "c9x-complex" library,
originating from the "cephes" math library, see
http://www.netlib.org/cephes/, from Stephen L. Moshier, incorporated and
redistributed with the NetBSD license by permission of the author.
Error behaviour and other boundary conditions (branch cuts)
need to be looked at.
For namespace sanity, I've done the rename/weak alias procedure to
most of the exported functions which are also used internally.
Didn't do so for sin/cos(f) yet because assembler implementations use
them directly, and renaming functions shared between the main libm
and the machine specific "overlay" might raise binary compatibility
issues.
