summaryrefslogtreecommitdiffstats
path: root/lib/msun
Commit message (Collapse)AuthorAgeFilesLines
* 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-194-4/+124
| | | | | | | | - 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-094-7/+146
| | | | | | | | | | | | | | | | | | | | | 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-064-6/+94
| | | | | | | 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.
* Eliminate double whitespace.ru2004-07-033-7/+7
|
* Mechanically kill hard sentence breaks.ru2004-07-024-6/+11
|
* Markup, grammar, punctuation.ru2004-07-013-10/+10
|
* Implement and document fdim{,f,l}, fmax{,f,l}, and fmin{,f,l}.das2004-06-3011-7/+570
|
* s/ARCH/ARCH_SUBDIR/g -- This reduces the chance of possible conflictsmarcel2004-06-241-3/+3
| | | | | | with the user's environment. Wondered why his cross-builds kept failing: marcel
* Completely remove s_ilogb.S as the assembler implementation gives very littlestefanf2004-06-202-84/+1
| | | | | | speed improvement to none at all over the MI version. Submitted by: bde
* Uncomment some functions that we now support.das2004-06-201-3/+3
|
* Cross-reference round(3) and trunc(3) as appropriate.das2004-06-203-3/+8
|
* Connect scalbln(), trunc(), and the associated documentation to the build.das2004-06-201-4/+6
|
* Declare scalbln(), scalblnf(), trunc(), and truncf().das2004-06-201-0/+4
|
* Implement trunc() and truncf().das2004-06-203-0/+188
|
* Add trivial implementations of scalbln() and scalblnf().das2004-06-202-4/+59
| | | | | | | | | 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.
* Document ilogb()'s return values in terms of the FP_ILOGB* macros.stefanf2004-06-191-2/+5
|
* Return the same result as the MI version for 0.0, INFINITY and NaN.stefanf2004-06-191-1/+31
| | | | Reviewed by: standards@
* 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@
* Memory's free, but all the world ain't a VAX anymore. Bring math.3das2004-06-191-364/+206
| | | | | | | | | | | | kicking and screaming into the 1980's. This change converts most of the markup from man(7) to mdoc(7) format, and I believe it removes or updates everything that was flat out wrong. However, much work is still needed to sanitize the markup, improve coverage, and reduce overlap with other manpages. Some of the sections would better belong in a philosophy_of_w_kahan.3 manpage, but they are informative and remain at least as reminders of topics to cover. Reviewed by: doc@, trhodes@
* The references to scalbn and scalbnf should be scalb and scalbf.das2004-06-121-2/+5
| | | | | | (The former are actually useful, and ieee_test(3) only documents functions that aren't.) Add a sentence describing the domain of scalb() and scalbf().
* Shift the FPSR contents by the correct amount so feupdateenv() raisesdas2004-06-111-1/+1
| | | | the correct exceptions from the old environment.
* Insert a missing '~' in feholdexcept(), so that it correctly clearsdas2004-06-111-1/+1
| | | | the exception flags in the mxcsr as well as the x87 FPU.
* 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-075-2/+183
| | | | | | PR: 59797 Submitted by: "Steven G. Kargl" <kargl@troutmask.apl.washington.edu> Reviewed by: bde (earlier version, last year)
* Add fenv.h, fenv.c, and the associated documentation to the libmdas2004-06-061-5/+12
| | | | | | | build. To facilitate this, add ${.CURDIR}/${ARCH} to make's search path unconditionally. Reviewed by: standards@
* Add documentation for:das2004-06-064-0/+601
| | | | | | | | | | - fenv(3) - feclearexcept(3), fegetexceptflag(3), feraiseexcept(3), fesetexceptflag(3), fetestexcept(3) - fegetround(3), fesetround(3) - fegetenv(3), feholdexcept(3), fesetenv(3), feupdateenv(3) Reviewed by: standards@
* Add an fenv.h implementation for the sparc64 port.das2004-06-062-0/+280
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the powerpc port.das2004-06-062-0/+282
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the ia64 port.das2004-06-062-0/+280
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the i386 port.das2004-06-062-0/+263
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the arm port.das2004-06-062-0/+230
| | | | | | | | It does not appear to be possible to cross-build arm from i386 at the moment, and I have no ARM hardware anyway. Thus, I'm sure there are bugs. I will gladly fix these when the arm port is more mature. Reviewed by: standards@
* Add an fenv.h implementation for the amd64 port.das2004-06-062-0/+333
| | | | Reviewed by: standards@
* Add an fenv.h implementation for the alpha port. All of the standarddas2004-06-062-0/+315
| | | | | | | | | | | | | | features appear to work, subject to the caveat that you tell gcc you want standard rather than recklessly fast behavior (-mieee-with-inexact -mfp-rounding-mode=d). The non-standard feature of delivering a SIGFPE when an application raises an unmasked exception does not work, presumably due to a kernel bug. This isn't so bad given that floating-point exceptions on the Alpha architecture are not precise, so making them useful in userland requires a significant amount of wizardry. Reviewed by: standards@
* 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-3010-0/+319
| | | | | | | needed for cases where GCC's builtin functions cannot be used and for compilers that don't know about them. Approved by: das (mentor)
* Remove some kludges designed to ensure that the compiler didn't rounddas2004-05-172-87/+10
| | | | | | | | | | constants the wrong way on the VAX. Instead, use C99 hexadecimal floating-point constants, which are guaranteed to be exact on binary IEEE machines. (The correct hexadecimal values were already provided in the source, but not used.) Also, convert the constants to lowercase to work around a gcc bug that wasn't fixed until gcc 3.4.0. Prompted by: stefanf
* Add an implementation of copysignl(), a long double version of copysign().stefanf2004-05-074-4/+57
| | | | Approved by: das (mentor)
* Add an MLINK for fabsl().stefanf2004-05-071-1/+1
| | | | Approved by: das (mentor)
OpenPOWER on IntegriCloud