summaryrefslogtreecommitdiffstats
path: root/lib/msun/src
Commit message (Collapse)AuthorAgeFilesLines
...
* 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@
* Fix a bug where rintf() rounded the wrong way in round-to-nearest modedas2004-06-091-26/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | on all inputs of the form x.75, where x is an even integer and log2(x) = 21. A similar problem occurred when rounding upward. The bug involves the following snippet copied from rint(): i>>=1; if((i0&i)!=0) i0 = (i0&(~i))|((0x100000)>>j0); The constant 0x100000 should be 0x200000. Apparently this case was never tested. It turns out that the bit manipulation is completely superfluous anyway, so remove it. (It tries to simulate 90% of the rounding process that the FPU does anyway.) Also, the special case of +-0 is handled twice (in different ways), so remove the second instance. Throw in some related simplifications from bde: - Work around a bug where gcc fails to clip to float precision by declaring two float variables as volatile. Previously, we tricked gcc into generating correct code by declaring some float constants as doubles. - Remove additional superfluous bit manipulation. - Minor reorganization. - Include <sys/types.h> explicitly. Note that some of the equivalent lines in rint() also appear to be unnecessary, but I'll defer to the numerical analysts who wrote it, since I can't test all 2^64 cases. Discussed with: bde
* Include <sys/cdefs.h> earlier to get the various visibility constants.das2004-06-091-2/+1
| | | | Previously, we were relying on <sys/_types.h> to include it implicitly.
* Add round(3) and roundf(3) and the associated documentation.das2004-06-073-0/+108
| | | | | | PR: 59797 Submitted by: "Steven G. Kargl" <kargl@troutmask.apl.washington.edu> Reviewed by: bde (earlier version, last year)
* Fixed lots of 1 ULP errors caused by a broken approximation for pi/2.bde2004-06-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | We approximate pi with more than float precision using pi_hi+pi_lo in the usual way (pi_hi is actually spelled pi in the source code), and expect (float)0.5*pi_lo to give the low part of the corresponding approximation for pi/2. However, the high part for pi/2 (pi_o_2) is rounded to nearest, which happens to round up, while the high part for pi was rounded down. Thus pi_o_2+(float)0.5*pi (in infinite precision) was a very bad approximation for pi/2 -- the low term has the wrong sign and increases the error drom less than half an ULP to a full ULP. This fix rounds up instead of down for pi_hi. Consistently rounding down instead of up should work, and is the method used in e_acosf.c and e_asinf.c. The reason for the difference is that we sometimes want to return precisely pi/2 in e_atan2f.c, so it is convenient to have a correctly rounded (to nearest) value for pi/2 in a variable. a_acosf.c and e_asinf.c also differ in directly approximating pi/2 instead pi; they multiply by 2.0 instead of dividing by 0.5 to convert the approximation. These complications are not directly visible in the double precision versions because rounding to nearest happens to round down.
* Port a bugfix from FDLIBM 5.3. The bug really only applies to tan()das2004-06-021-8/+24
| | | | | | | | | | | | and not tanf() because float type can't represent numbers large enough to trigger the problem. However, there seems to be a precedent that the float versions of the fdlibm routines should mirror their double counterparts. Also update to the FDLIBM 5.3 license. Obtained from: FDLIBM Reviewed by: exhaustive comparison
* Merge a bugfix from FDLIBM 5.3 to ensure that the error in tan()das2004-06-021-10/+24
| | | | | | is always less than 1 ulp. Also update to the 5.3 license. Obtained from: FDLIBM
* Merged from double precision case (e_pow.c 1.10: sign fixes).bde2004-06-011-13/+14
|
* Fixed the sign of the result in some overflow and underflow cases (onesbde2004-06-011-17/+18
| | | | | | | | | | | | | | | where the exponent is an odd integer and the base is negative). Obtained from: fdlibm-5.3 Sun finally released a new version of fdlibm just a coupe of weeks ago. It only fixes 3 bugs (this one, another one in pow() that we already have (rev.1.9), and one in tan(). I've learned too much about powf() lately, so this fix was easy to merge. The patch is not verbatim, because our base version has many differences for portability and I didn't like global renaming of an unrelated variable to keep it separate from the sign variable. This patch uses a new variable named sn for the sign.
* Fixed another precision bug in powf(). This one is in the computationbde2004-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | [t=p_l+p_h High]. We multiply t by lg2_h, and want the result to be exact. For the bogus float case of the high-low decomposition trick, we normally discard the lowest 12 bits of the fraction for the high part, keeping 12 bits of precision. That was used for t here, but it doesnt't work because for some reason we only discard the lowest 9 bits in the fraction for lg2_h. Discard another 3 bits of the fraction for t to compensate. This bug gave wrong results like: powf(0.9999999, -2.9999995) = 1.0000002 (should be 1.0000001) hex values: 3F7FFFFF C03FFFFE 3F800002 3F800001 As explained in the log for the previous commit, the bug is normally masked by doing float calculations in extra precision on i386's, but is easily detected by ucbtest on systems that don't have accidental extra precision. This completes fixing all the bugs in powf() that were routinely found by ucbtest.
* Fixed 2 bugs in the computation /* t_h=ax+bp[k] High */.bde2004-06-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) The bit for the 1.0 part of bp[k] was right shifted by 4. This seems to have been caused by a typo in converting e_pow.c to e_powf.c. (2) The lower 12 bits of ax+bp[k] were not discarded, so t_h was actually plain ax+bp[k]. This seems to have been caused by a logic error in the conversion. These bugs gave wrong results like: powf(-1.1, 101.0) = -15158.703 (should be -15158.707) hex values: BF8CCCCD 42CA0000 C66CDAD0 C66CDAD4 Fixing (1) gives a result wrong in the opposite direction (hex C66CDAD8), and fixing (2) gives the correct result. ucbtest has been reporting this particular wrong result on i386 systems with unpatched libraries for 9 years. I finally figured out the extent of the bugs. On i386's they are normally hidden by extra precision. We use the trick of representing floats as a sum of 2 floats (one much smaller) to get extra precision in intermediate calculations without explicitly using more than float precision. This trick is just a pessimization when extra precision is available naturally (as it always is when dealing with IEEE single precision, so the float precision part of the library is mostly misimplemented). (1) and (2) break the trick in different ways, except on i386's it turns out that the intermediate calculations are done in enough precision to mask both the bugs and the limited precision of the float variables (as far as ucbtest can check). ucbtest detects the bugs because it forces float precision, but this is not a normal mode of operation so the bug normally has little effect on i386's. On systems that do float arithmetic in float precision, e.g., amd64's, there is no accidental extra precision and the bugs just give wrong results.
* Add implementations for cimag{,f,l}, creal{,f,l} and conj{,f,l}. They arestefanf2004-05-309-0/+315
| | | | | | | needed for cases where GCC's builtin functions cannot be used and for compilers that don't know about them. Approved by: das (mentor)
* Add an implementation of copysignl(), a long double version of copysign().stefanf2004-05-072-0/+44
| | | | Approved by: das (mentor)
* Make sure that symbols are declared in math.h iff the appropriatedas2004-04-251-65/+68
| | | | | | | | | | | | | | namespaces are visible. Previously, math.h failed to hide some C99-, XSI-, and BSD-specific symbols in certain compilation environments. The referenced PR has a nice listing of the appropriate conditions for making symbols visible in math.h. The only non-stylistic difference between the patch in the PR and this commit is that I superfluously test for __BSD_VISIBLE in a few places to be more explicit about which symbols have historically been part of the FreeBSD environment. PR: 65939 Submitted by: Stefan Farfeleder <stefan@fafoe.narf.at>
* Remove a stale comment referring to values.h, which has never beendas2004-04-251-6/+1
| | | | | | part of FreeBSD. PR: 65939
* Initial support for C99's (or is it POSIX.1-2001's?) MATH_ERRNO,bde2004-03-121-0/+6
| | | | | | | | | | | MATH_ERREXCEPTION and math_errhandling, so that C99 applications at least have the possibility of determining that errno is not set for math functions. Set math_errhandling to the non-standard-conforming value of 0 for now to indicate that we don't support either method of reporting errors. We intentionally don't support MATH_ERRNO because errno is a mistake, and we are missing support for MATH_ERREXCEPTION (<fenv.h>, compiler support for <fenv.h>, and actually setting the exception flags correctly).
* Fix a problem where libm compiled under 5.X would depend on featuresdas2003-10-272-2/+8
| | | | | | | | | | | | | | that are only in libc.so.5. This broke some 4.X applications linked to libm and run under 5.X. Background: In C99, isinf() and isnan() cannot be implemented as regular functions. We use macros that call libc functions in 5.X, but for libm-internal use, we need to use the old versions until the next time libm's major version number is bumped. Submitted by: bde Reported by: imp, kris
* Better safe than clever.des2003-10-251-2/+5
| | | | Submitted by: das
* - fabsl.c should be named s_fabsl.c for consistency with libmsun'sdes2003-10-251-1/+4
| | | | | | | | | | | | | | | documented naming scheme (unfortunately the documentation isn't in the tree as far as I can tell); no repocopy is required as there is no history to preserve. - replace simple and almost-correct implementation with slightly hackish but definitely correct implementation (tested on i386, alpha, sparc64) which requires pulling in fpmath.h and the MD _fpmath.h from libc. - try not to make a mess of the Makefile in the process. - enterprising minds are encouraged to implement more C99 long double functions.
* Add prototypes for all long double functions in C99. Leave them alldes2003-10-231-0/+67
| | | | #if 0'd out, except for fabsl(3) which I've implemented.
* Implement fabsl(3), allowing the world to build with -fno-builtin.des2003-10-231-0/+37
|
* Only provide one copy of the math functions. If we provide a MD function,peter2003-07-2325-65/+25
| | | | | | | | do not also provide a __generic_XXX version as well. This is how we used to runtime select the generic vs i387 versions on the i386 platform. This saves a pile of #defines in the src/math_private.h file to undo the __generic_XXX renames in some of the *.c files.
* No longer need the internal __get_hw_float() function.peter2003-07-231-50/+0
|
* Now that we do not need to do runtime detection for the broken defaultpeter2003-07-232-2/+14
| | | | | | | | | fp emulator, stop doing the runtime selection of hardware or emulated floating point operations on i386. Note that I have not suppressed the duplicate compiles yet. While here, fix the alpha. It has provided specific copysign/copysignf functions since the beginning of time, but they have never been used.
* Fix two misuses of __BSD_VISIBLE.mike2003-05-221-2/+2
| | | | | Submitted by: bde Approved by: re
* AMD64 support (another IEEEFP platform)peter2003-04-301-1/+1
|
* Fix braino in definition of isfinite().das2003-04-041-1/+1
| | | | | Noticed by: marcus Pointy hat to: das
* - gamma_r, lgamma_r, gammaf_r, and lgammaf_r were protected by _REENTRANTimp2003-02-261-4/+4
| | | | | | | | | | in math.h; the consensus here was that __BSD_VISIBLE was correct instead. - gamma_r, lgamma_r, gammaf_r, and lgammaf_r had no documentation in the lgamma(3) manpage. Reviewed by: standards@ Submitted by: Ben Mesander
* o Implement C99 classification macros isfinite(), isinf(), isnan(),mike2003-02-123-12/+32
| | | | | | | | | isnormal(). The current isinf() and isnan() are perserved for binary compatibility with 5.0, but new programs will use the macros. o Implement C99 comparison macros isgreater(), isgreaterequal(), isless(), islessequal(), islessgreater(), isunordered(). Submitted by: David Schultz <dschultz@uclink.Berkeley.EDU>
* Implement C99's signbit() macro.mike2003-02-111-0/+2
|
OpenPOWER on IntegriCloud