summaryrefslogtreecommitdiffstats
path: root/lib/msun/src
Commit message (Collapse)AuthorAgeFilesLines
* Replace strong references with weak references. There's nodas2005-03-074-7/+7
| | | | | | | | particularly good reason to do this, except that __strong_reference does type checking, whereas __weak_reference does not. On Alpha, the compiler won't accept a 'long double' parameter in place of a 'double' parameter even thought the two types are identical.
* Remove an obsolete sentence from a comment.stefanf2005-03-071-2/+1
|
* - If z is 0, one of x or y is 0, and the other is infinite, raisedas2005-03-071-2/+18
| | | | | | | an invalid exception and return an NaN. - If a long double has 113 bits of precision, implement fma in terms of simple long double arithmetic instead of complicated double arithmetic. - If a long double is the same as a double, alias fma as fmal.
* Remove ldexp and ldexpf. The former is in libc, and the latter isdas2005-03-072-59/+0
| | | | | | identical to scalbnf, which is now aliased as ldexpf. Note that the old implementations made the mistake of setting errno and were the only libm routines to do so.
* - Define FP_FAST_FMA for sparc64, since fma() is now implemented usingdas2005-03-071-4/+12
| | | | | | | sparc64's 128-bit long doubles. - Define FP_FAST_FMAL for ia64. - Prototypes for fmal, frexpl, ldexpl, nextafterl, nexttoward{,f,l}, scalblnl, and scalbnl.
* Alias scalbn as ldexpl and scalbnl on platforms where long double isdas2005-03-071-0/+8
| | | | the same as double.
* - Implement scalblnl.das2005-03-071-2/+34
| | | | | | - In scalbln and scalblnf, check the bounds of the second argument. This is probably unnecessary, but strictly speaking, we should report an error if someone tries to compute scalbln(x, INT_MAX + 1ll).
* Implement nexttowardf. This is used on both platforms with 11-bitdas2005-03-071-0/+60
| | | | exponents and platforms with 15-bit exponents for long doubles.
* Implement nexttoward and nextafterl; the latter is also known asdas2005-03-072-0/+155
| | | | | | | | | | | nexttowardl. These are not needed on machines where long doubles look like IEEE-754 doubles, so the implementation only supports the usual long double formats with 15-bit exponents. Anything bizarre, such as machines where floating-point and integer data have different endianness, will cause problems. This is the case with big endian ia64 according to libc/ia64/_fpmath.h. Please contact me if you managed to get a machine running this way.
* - Try harder to trick gcc into not optimizing away statementsdas2005-03-072-8/+19
| | | | | | that are intended to raise underflow and inexact exceptions. - On systems where long double is the same as double, nextafter should be aliased as nexttoward, nexttowardl, and nextafterl.
* Implement frexpl.das2005-03-071-0/+62
|
* Alias frexp as frexpl on platforms where a long double is the same asdas2005-03-071-0/+7
| | | | a double.
* Implement fmal.das2005-03-071-0/+170
|
* Add scalbnl, also known as as ldexpl.das2005-03-071-0/+71
|
* Alias scalbnf as ldexpf. The two are identical in binarydas2005-03-071-0/+4
| | | | floating-point formats.
* Revert rev 1.8, which causes small (e.g. 2 ulp) errors for somedas2005-02-241-8/+13
| | | | | | | | | inputs. The trouble with replacing two floats with a double is that the latter has 6 extra bits of precision, which actually hurts accuracy in many cases. All of the constants are optimal when float arithmetic is used, and would need to be recomputed to do this right. Noticed by: bde (ucbtest)
* Use double arithmetic instead of simulating it with two floats. Thisdas2005-02-211-13/+8
| | | | | | | results in a performance gain on the order of 10% for amd64 (sledge), ia64 (pluto1), i386+SSE (Pentium 4), and sparc64 (panther), and a negligible improvement for i386 without SSE. (The i386 port still uses the hardware instruction, though.)
* Fix a small scripting snafu in the previous revision.das2005-02-041-2/+2
|
* Reduce diffs against vendor source (Sun fdlibm 5.3).das2005-02-0428-428/+476
|
* Remove wrappers and other cruft intended to support SVID, mistakes indas2005-02-0457-3225/+60
| | | | | | | C90, and other arcana. Most of these features were never fully supported or enabled by default. Ok: bde, stefanf
* Update comment to reflect the code change in the previous revision.das2005-01-232-2/+2
| | | | Noticed by: ceri
* If x == y, return y, not x. C99 (though not IEEE 754) requires thatdas2005-01-232-2/+2
| | | | nextafter(+0.0, -0.0) returns -0.0 and nextafter(-0.0, +0.0) returns +0.0.
* Add fma() and fmaf(), which implement a fused multiply-add operation.das2005-01-223-0/+230
|
* Most libm routines depend on the rounding mode and/or set exceptiondas2005-01-151-31/+29
| | | | | | | | | | | | | | flags, so they are not pure. Remove the __pure2 annotation from them. I believe that the following routines and their float and long double counterparts are the only ones here that can be __pure2: copysign is* fabs finite fmax fmin fpclassify ilogb nan signbit When gcc supports FENV_ACCESS, perhaps there will be a new annotation that allows the other functions to be considered pure when FENV_ACCESS is off. Discussed with: bde
* Braino. Revert rev 1.50.das2005-01-151-0/+7
| | | | Pointy hat to: das
* Set math_errhandling to MATH_ERREXCEPT. Now that we have fenv.h, wedas2005-01-141-1/+1
| | | | | | basically support this, subject to gcc's lack of FENV_ACCESS support. In any case, the previous setting of math_errhandling to 0 is not allowed by POSIX.
* Remove some #if 0'd code.das2005-01-141-7/+0
|
* The isnormal() in rev 1.2 should have been isfinite() so subnormalsdas2005-01-132-2/+2
| | | | | | round correctly. Noticed by: stefanf
* Implement and document ceill().stefanf2005-01-132-1/+98
|
* Implement floorl().stefanf2005-01-122-1/+98
|
* Whitespace nit.stefanf2005-01-121-1/+1
|
* Add MI implementations of [l]lrint[f]() and [l]lround[f]().das2005-01-119-0/+193
| | | | Discussed with: bde
* Add and document ilogbl(), a long double version of ilogb().stefanf2004-10-112-0/+56
|
* Use the FP_ILOG macros from <math.h> rather than hardcoded return values.stefanf2004-10-092-6/+13
| | | | | | Also be prepared for FP_ILOGBNAN != INT_MAX. Reviewed by: md5
* Further refine some #ifs:das2004-09-171-2/+2
| | | | | | | - Simplify the logic by using __GNUC_PREREQ__. Suggested by stefanf. - Make math.h compile with old (pre-8.0) versions of icc. Submitted by sf [sic].
* Replace s_isnan.c and s_isnanf.c with the more compact s_isnan.c fromdas2004-08-052-66/+52
| | | | | | | libc. The externally-visible effect of this is to add __isnanl() to libm, which means that libm.so.2 can once again link against libc.so.4 when LD_BIND_NOW is set. This was broken by the addition of fdiml(), which calls __isnanl().
* Use isnormal() instead of fpclassify() to avoid dependency on libc.so.5.das2004-08-052-6/+2
|
* Work around known GCC 3.4.x problem and use ANSI prototype for dremf().kan2004-07-281-2/+2
|
* Fix two bugs in the signbit() macro, which was implemented last year:das2004-07-192-1/+64
| | | | | | | | - It was added to libc instead of libm. Hopefully no programs rely on this mistake. - It didn't work properly on large long doubles because its argument was converted to type double, resulting in undefined behavior.
* Fix minor namespace pollution: The prototypes for f{dim,max,min}(),stefanf2004-07-171-6/+6
| | | | | nearbyint(), round() and trunc() shouldn't be visible when compiling with -D_XOPEN_SOURCE=500.
* Tweak the conditions under which certain gcc builtins are used:das2004-07-161-2/+2
| | | | | | | | | | | | - Unlike the builtin relational operators, builtin floating-point constants were not available until gcc 3.3, so account for this.[1] - Apparently some versions of the Intel C Compiler fallaciously define __GNUC__ without actually being compatible with the claimed gcc version. Account for this, too.[2] [1] Noticed by: Christian Hiris <4711@chello.at> [2] Submitted by: Alexander Leidinger <Alexander@Leidinger.net>
* Remove the declaration of isnan() from this file. It is no longerdas2004-07-092-6/+0
| | | | needed as of math.h v1.40, and its prototype is incorrect here.
* Implement the classification macros isfinite(), isinf(), isnan(), anddas2004-07-093-6/+144
| | | | | | | | | | | | | | | | | | | | | isnormal() the hard way, rather than relying on fpclassify(). This is a lose in the sense that we need a total of 12 functions, but it is necessary for binary compatibility because we have never bumped libm's major version number. In particular, isinf(), isnan(), and isnanf() were BSD libc functions before they were C99 macros, so we can't reimplement them in terms of fpclassify() without adding a dependency on libc.so.5. I have tried to arrange things so that programs that could be compiled in FreeBSD 4.X will generate the same external references when compiled in 5.X. At the same time, the new macros should remain C99-compliant. The isinf() and isnan() functions remain in libc for historical reasons; however, I have moved the functions that implement the macros isfinite() and isnormal() to libm where they belong. Moreover, half a dozen MD versions of isinf() and isnan() have been replaced with MI versions that work equally well. Prodded by: kris
* Define the following macros in terms of [gi]cc builtins when thedas2004-07-091-0/+29
| | | | | | | | | | | | | | | | | | builtins are available: HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY, and NAN. These macros now expand to floating-point constant expressions rather than external references, as required by C99. Other compilers will retain the historical behavior. Note that it is not possible say, e.g. #define HUGE_VAL 1.0e9999 because the above may result in diagnostics at translation time and spurious exceptions at runtime. Hence the need for compiler support for these features. Also use builtins to implement the macros isgreater(), isgreaterequal(), isless(), islessequal(), islessgreater(), and isunordered() when such builtins are available. Although the old macros are correct, the builtin versions are much faster, and they avoid double-expansion problems.
* Add C99's nearbyint{,f}() functions as wrappers around rint().das2004-07-062-0/+56
| | | | | | | These trivial implementations are about 25 times slower than rint{,f}() on x86 due to the FP environment save/restore. They should eventually be redone in terms of fegetround() and bit fiddling.
* Implement and document fdim{,f,l}, fmax{,f,l}, and fmin{,f,l}.das2004-06-308-3/+380
|
* Declare scalbln(), scalblnf(), trunc(), and truncf().das2004-06-201-0/+4
|
* Implement trunc() and truncf().das2004-06-202-0/+114
|
* Add trivial implementations of scalbln() and scalblnf().das2004-06-201-0/+44
| | | | | | | | | These routines are specified in C99 for the sake of architectures where an int isn't big enough to represent the full range of floating-point exponents. However, even the 128-bit long double format has an exponent smaller than 15 bits, so for all practical purposes, scalbln() and scalblnf() are aliases for scalbn() and scalbnf(), respectively.
* Our MI implementation of ilogb() returns -INT_MAX for the argument 0.0 ratherstefanf2004-06-191-2/+3
| | | | | | | than INT_MIN, so adjust FP_ILOGB0 to reflect this. Use <machine/_limits.h> for INT_MAX's value while there. Reviewed by: standards@
OpenPOWER on IntegriCloud