summaryrefslogtreecommitdiffstats
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Sigh, the weak reference for ceill(), floorl() and truncl() was inbde2008-02-153-6/+10
| | | | | | | unreachable code due to a missing include. This kept arm and powerpc broken. Reported by: sam, grehan
* Oops, the weak reference for ceill(), floorl() and truncl() was in thebde2008-02-146-12/+12
| | | | | | wrong file. This broke arm and powerpc. Reported by: grehan
* Use the expression fabs(x+0.0)+fabs(y+0.0) instad of a+b (where a isbde2008-02-142-8/+8
| | | | | | | | | | | | | | | | | | | | | | | |x| or |y| and b is |y| or |x|) when mixing NaN arg(s). hypot*() had its own foot shooting for mixing NaNs -- it swaps the args so that |x| in bits is largest, but does this before quieting signaling NaNs, so on amd64 (where the result of adding NaNs depends on the order) it gets inconsistent results if setting the quiet bit makes a difference, just like a similar ia64 and i387 hardware comparison. The usual fix (see e_powf.c 1.13 for more details) of mixing using (a+0.0)+-(b+0.0) doesn't work on amd64 if the args are swapped (since the rder makes a difference with SSE). Fortunately, the original args are unchanged and don't need to be swapped when we let the hardware decide the mixing after quieting them, but we need to take their absolute value. hypotf() doesn't seem to have any real bugs masked by this non-bug. On amd64, its maximum error in 2^32 trials on amd64 is now 0.8422 ulps, and on i386 the maximum error is unchanged and about the same, except with certain CFLAGS it magically drops to 0.5 (perfect rounding). Convert to __FBSDID().
* _pthread_mutex_isowned_np(): use a more reliable method; the current codedes2008-02-141-1/+1
| | | | | | will work in simple cases, but may fail in more complicated ones. Reviewed by: davidxu
* Fix the hi+lo decomposition for 2/(3ln2). The decomposition needs tobde2008-02-141-2/+2
| | | | | | | | | | | | be into 12+24 bits of precision for extra-precision multiplication, but was into 13+24 bits. On i386 with -O1 the bug was hidden by accidental extra precision, but on amd64, in 2^32 trials the bug caused about 200000 errors of more than 1 ulp, with a maximum error of about 80 ulps. Now the maximum error in 2^32 trials on amd64 is 0.8573 ulps. It is still 0.8316 ulps on i386 with -O1. The nearby decomposition of 1/ln2 and the decomposition of 2/(3ln2) in the double precision version seem to be sub-optimal but not broken.
* Use the expression (x+0.0)-(y+0.0) instead of x+y when mixing NaN arg(s).bde2008-02-142-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses 2 tricks to improve consistency so that more serious problems aren't hidden in simple regression tests by noise for the NaNs: - for a signaling NaN, adding 0.0 generates the invalid exception and converts to a quiet NaN, and doesn't have too many effects for other types of args (it converts -0 to +0 in some rounding modes, but that hopefully doesn't change the result after adding the NaN arg). This avoids some inconsistencies on i386 and ia64. On these arches, the result of an operation on 2 NaNs is apparently the largest or the smallest of the NaNs as bits (consistently largest or smallest for each arch, but the opposite). I forget which way the comparison goes and if the sign bit affects it. The quiet bit is is handled poorly by not always setting it before the comparision or ignoring it. Thus if one of the args was originally a signaling NaN and the other was originally a quiet NaN, then the result depends too much on whether the signaling NaN has been quieted at this point, which in turn depends on optimizations and promotions. E.g., passing float signaling NaNs to double functions must quiet them on conversion; on i387, loading a signaling NaN of type float or double (but not long double) into a register involves a conversion, so it quiets signaling NaNs, so if the addition has 2 register operands than it only sees quiet NaNs, but if the addition has a memory operand then it sees a signaling NaN iff it is in the memory operand. - subtraction instead of addition is used to avoid a dubious optimization in old versions of gcc. For SSE operations, mixing of NaNs apparently always gives the target operand. This is not as good as the i387 and ia64 behaviour. It doesn't mix NaNs at all, and makes addition not quite commutative. Old versions of gcc sometimes rewrite x+y to y+x and thus give different results (in bits) for NaNs. gcc-3.3.3 rewrites x+y to y+x for one of pow() and powf() but not the other, so starting from float NaN args x and y, powf(x, y) was almost always different from pow(x, y). These tricks won't give consistency of 2-arg float and double functions with long double ones on amd64, since long double ones use the i387 which has different semantics from SSE. Convert to __FBSDID().
* s_ceill.cbde2008-02-133-9/+6
| | | | | s_floorl.c s_truncl.c
* On arches where long double is the same as double, alias ceil(), floor()bde2008-02-134-6/+19
| | | | | | | and trunc() to the corresponding long double functions. This is not just an optimization for these arches. The full long double functions have a wrong value for `huge', and the arches without full long doubles depended on it being wrong.
* Fix the C version of ceill(x) for -1 < x <= -0 in all rounding modes.bde2008-02-131-1/+1
| | | | The result should be -0, but was +0.
* - Remove duplicate tputs.3 from MLINK. As we use termcap in the bsae, removerafan2008-02-131-1/+0
| | | | | | | the one links to curs_terminfo. Submitted by: David Naylor <blackdragon at highveldmail.co.za> MFC after: 3 days
* Fix exp2*(x) on signaling NaNs by returning x+x as usual.bde2008-02-134-4/+4
| | | | | | | | | | | | | | | This has the side effect of confusing gcc-4.2.1's optimizer into more often doing the right thing. When it does the wrong thing here, it seems to be mainly making too many copies of x with dependency chains. This effect is tiny on amd64, but in some cases on i386 it is enormous. E.g., on i386 (A64) with -O1, the current version of exp2() should take about 50 cycles, but took 83 cycles before this change and 66 cycles after this change. exp2f() with -O1 only speeded up from 51 to 47 cycles. (exp2f() should take about 40 cycles, on an Athlon in either i386 or amd64 mode, and now takes 42 on amd64). exp2l() with -O1 slowed down from 155 cycles to 123 for some args; this is unimportant since the i386 exp2l() is a fake; the wrong thing for it seems to involve branch misprediction.
* Rearrange the polynomial evaluation for better parallelism. This isbde2008-02-131-3/+4
| | | | | | | | | | | | | | faster on all machines tested (old Celeron (P2), A64 (amd64 and i386) and ia64) except on ia64 when compiled with -O1. It takes 2 more multiplications, so it will be slower on old machines. The speedup is about 8 cycles = 17% on A64 (amd64 and i386) with best CFLAGS and some parallelism in the caller. Move the evaluation of 2**k up a bit so that it doesn't compete too much with the new polynomial evaluation. Unlike the previous optimization, this rearrangement cannot change the result, so compilers and CPU schedulers can do it, but they don't do it quite right yet. This saves a whole 1 or 2 cycles on A64.
* Use hardware remainder on amd64 since it is 5 to 10 times faster thanbde2008-02-133-1/+78
| | | | software remainder and is already used for remquo().
* style.Makefile(5)obrien2008-02-136-6/+6
|
* style(9)obrien2008-02-132-6/+6
|
* Change readlink(2)'s return type and type of the last argumentru2008-02-121-4/+4
| | | | | | to match POSIX. Prodded by: Alexey Lyashkov
* Fix remainder() and remainderf() in round-towards-minus-infinity modebde2008-02-122-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | when the result is +-0. IEEE754 requires (in all rounding modes) that if the result is +-0 then its sign is the same as that of the first arg, but in round-towards-minus-infinity mode an uncorrected implementation detail always reversed the sign. (The detail is that x-x with x's sign positive gives -0 in this mode only, but the algorithm assumed that x-x always has positive sign for such x.) remquo() and remquof() seem to need the same fix, but I cannot test them yet. Use long doubles when mixing NaN args. This trick improves consistency of results on at least amd64, so that more serious problems like the above aren't hidden in simple regression tests by noise for the NaNs. On amd64, hardware remainder should be used since it is about 10 times faster than software remainder and is already used for remquo(), but it involves using the i387 even for floats and doubles, and the i387 does NaN mixing which is better than but inconsistent with SSE NaN mixing. Software remainder() would probably have been inconsistent with software remainderl() for the same reason if the latter existed. Signaling NaNs cause further inconsistencies on at least ia64 and i386. Use __FBSDID().
* - Update build glues for ncurses 5.6 snapshot 20080209rafan2008-02-112-6/+11
| | | | - While I'm here, sort macro defines in ncurses_cfg.h
* After issueing a ntpdate [1] I noticed it's already 2008, reflect thatremko2008-02-111-1/+1
| | | | | | in the last modified date. Noticed by: brueffer [1]
* Fix typo (s/existance/existence/)remko2008-02-111-2/+2
| | | | Noticed by: ceri
* Use double precision for z and thus for the entire calculation ofbde2008-02-111-3/+4
| | | | | | | | | | | | | | | | | | | | exp2(i/TBLSIZE) * p(z) instead of only for the final multiplication and addition. This fixes the code to match the comment that the maximum error is 0.5010 ulps (except on machines that evaluate float expressions in extra precision, e.g., i386's, where the evaluation was already in extra precision). Fix and expand the comment about use of double precision. The relative roundoff error from evaluating p(z) in non-extra precision was about 16 times larger than in exp2() because the interval length is 16 times smaller. Its maximum was at least P1 * (1.0 ulps) * max(|z|) ~= log(2) * 1.0 * 1/32 ~= 0.0217 ulps (1.0 ulps from the addition in (1 + P1*z) with a cancelation error when z ~= -1/32). The actual final maximum was 0.5313 ulps, of which 0.0303 ulps must have come from the additional roundoff error in p(z). I can't explain why the additional roundoff error was almost 3/2 times larger than the rough estimate.
* As usual, use a minimax polynomial that is specialized for floatbde2008-02-091-7/+8
| | | | | | | | | | | | | | | | | | | | | | | precision. The new polynomial has degree 4 instead of 10, and a maximum error of 2**-30.04 ulps instead of 2**-33.15. This doesn't affect the final error significantly; the maximum error was and is about 0.5015 ulps on i386 -O1, and the number of cases with an error of > 0.5 ulps is increased from 13851 to 14407. Note that the error is only this close to 0.5 ulps due to excessive extra precision caused by compiler bugs on i386. The extra precision could be obtained intentionally, and is useful for keeping the error of the hyperbolic float functions below 1 ulp, since these functions are implemented using expm1f. My recent change for scaling by 2**k had the unintentional side effect of retaining extra precision for longer, so callers of expm1f see errors of more like 0.0015 ulps than 0.5015 ulps, and for the hyperbolic functions this reduces the maximum error from nearly about 2 ulps to about 0.75 ulps. This is about 10% faster on i386 (A64). expm1* is still very slow, but now the float version is actually significantly faster. The algorithm is very sophisticated but not very good except on machines with fast division.
* Fix a comment about coefficients and expand a related one.bde2008-02-091-2/+2
|
* Use memcpy(3) instead of the BSD-specific bcopy(3).des2008-02-083-6/+6
| | | | | Submitted by: Joerg Sonnenberger <joerg@britannica.bec.de> MFC after: 2 weeks
* s/MAXPATHLEN/PATH_MAX/ to reflect five-year old change to the code :)des2008-02-081-1/+1
| | | | | Submitted by: Joerg Sonnenberger <joerg@britannica.bec.de> MFC after: 2 weeks
* Fix a bug in lazy deallocation that was introduced whenjasone2008-02-081-7/+10
| | | | | | | | arena_dalloc_lazy_hard() was split out of arena_dalloc_lazy() in revision 1.162. Reduce thundering herd problems in lazy deallocation by randomly varying how many probes a thread does before taking the slow path.
* Fix truncl() when the result should be -0.0L. When the result is +-0.0L,bde2008-02-081-1/+2
| | | | | it must have the same sign as the arg in all rounding modes, but it was always +0.0L.
* Oops, fix the fix in rev.1.10. logb() and logbf() were broken onbde2008-02-081-5/+4
| | | | | | | denormals, and logb() remained broken after 1.10 because the fix for logbf() was incompletely translated. Convert to __FBSDID().
* Clean up manipulation of chunk page map elements to remove some tenuousjasone2008-02-081-362/+357
| | | | | | | | | | | assumptions about whether bits are set at various times. This makes adding other flags safe. Reorganize functions in order to inline i{m,c,p,s,re}alloc(). This allows the entire fast-path call chains for malloc() and free() to be inlined. [1] Suggested by: [1] Stuart Parmenter <stuart@mozilla.com>
* Use a better method of scaling by 2**k. Instead of adding to thebde2008-02-072-26/+16
| | | | | | | | | | | | | | | | | | | | | | | | exponent bits of the reduced result, construct 2**k (hopefully in parallel with the construction of the reduced result) and multiply by it. This tends to be much faster if the construction of 2**k is actually in parallel, and might be faster even with no parallelism since adjustment of the exponent requires a read-modify-wrtite at an unfortunate time for pipelines. In some cases involving exp2* on amd64 (A64), this change saves about 40 cycles or 30%. I think it is inherently only about 12 cycles faster in these cases and the rest of the speedup is from partly-accidentally avoiding compiler pessimizations (the construction of 2**k is now manually scheduled for good results, and -O2 doesn't always mess this up). In most cases on amd64 (A64) and i386 (A64) the speedup is about 20 cycles. The worst case that I found is expf on ia64 where this change is a pessimization of about 10 cycles or 5%. The manual scheduling for plain exp[f] is harder and not as tuned. Details specific to expm1*: - the saving is closer to 12 cycles than to 40 for expm1* on i386 (A64). For some reason it is much larger for negative args. - also convert to __FBSDID().
* Use a better method of scaling by 2**k. Instead of adding to thebde2008-02-076-55/+57
| | | | | | | | | | | | | | | | | | | | | exponent bits of the reduced result, construct 2**k (hopefully in parallel with the construction of the reduced result) and multiply by it. This tends to be much faster if the construction of 2**k is actually in parallel, and might be faster even with no parallelism since adjustment of the exponent requires a read-modify-wrtite at an unfortunate time for pipelines. In some cases involving exp2* on amd64 (A64), this change saves about 40 cycles or 30%. I think it is inherently only about 12 cycles faster in these cases and the rest of the speedup is from partly-accidentally avoiding compiler pessimizations (the construction of 2**k is now manually scheduled for good results, and -O2 doesn't always mess this up). In most cases on amd64 (A64) and i386 (A64) the speedup is about 20 cycles. The worst case that I found is expf on ia64 where this change is a pessimization of about 10 cycles or 5%. The manual scheduling for plain exp[f] is harder and not as tuned. This change ld128/s_exp2l.c has not been tested.
* Add missing #includedes2008-02-061-0/+1
| | | | | | Spotted by: tinderbox Submitted by: Pietro Cerutti <gahr@gahr.ch> Pointy hat to: des
* Yet another pointy hat: when I zapped FBSDprivate_1.1, I forgot to movedes2008-02-061-0/+1
| | | | its contents to FBSDprivate_1.0.
* Add pthread_mutex_isowned_np() here as well; libthr and libkse are supposeddes2008-02-062-0/+15
| | | | | | to have identical functionality. MFC after: 2 weeks
* Remove unnecessary prototype.des2008-02-061-1/+0
|
* Add pthread_mutex_isowned_np() so there is no need for an additionaldes2008-02-062-0/+2
| | | | | | prototype next to the implementation. MFC after: 2 weeks
* Previous commit had a typo that resulted in symbol versioning beingdes2008-02-061-1/+1
| | | | | | (silently) disabled for libkse... Pointy hat to: des
* Give libkse the same treatment as libthr re. symbol versioning.des2008-02-062-8/+2
| | | | MFC after: 2 weeks
* Convert pthread.map to the format expected by version_gen.awk, and modifydes2008-02-062-11/+3
| | | | | | the Makefile accordingly; libthr now explicitly uses libc's Versions.def. MFC after: 2 weeks
* Remove incorrectly added FBSDprivate_1.1 namespace, and move symbols whichdes2008-02-061-12/+4
| | | | are new in FreeBSD 8 to the appropriate namespace.
* Per discussion on -threads, rename _islocked_np() to _isowned_np().des2008-02-062-5/+5
|
* Add necessary cast for tolower() argument.des2008-02-061-2/+3
| | | | | Submitted by: Joerg Sonnenberger <joerg@britannica.bec.de> MFC after: 1 week
* As for the float trig functions and logf, use a minimax polynomialbde2008-02-061-6/+7
| | | | | | | | | | | | | that is specialized for float precision. The new polynomial has degree 5 instead of 11, and a maximum error of 2**-27.74 ulps instead of 2**-30.64. This doesn't affect the final error significantly; the maximum error was and is about 0.9101 ulps on amd64 -01 and the number of cases with an error of > 0.5 ulps is actually reduced by epsilon despite the larger error in the polynomial. This is about 15% faster on amd64 (A64), i386 (A64) and ia64. The asm version is still used instead of this on i386 since it is faster and more accurate.
* Track dirty unused pages so that they can be purged if they exceed ajasone2008-02-062-679/+973
| | | | | | | | | | | | | | | | | | | | | | | | | threshold, according to the 'F' MALLOC_OPTIONS flag. This obsoletes the 'H' flag. Try to realloc() large objects in place. This substantially speeds up incremental large reallocations in the common case. Fix a bug in arena_ralloc() that caused relocation of sub-page objects even if the old and new sizes were in the same size class. Maintain trees of runs and simplify the per-chunk page map. This allows logarithmic-time searching for sufficiently large runs in arena_run_alloc(), whereas the previous algorithm required linear time in the worst case. Break various large functions into smaller sub-functions, and inline only the functions that are in the fast path for small object allocation/deallocation. Remove an unnecessary check in base_pages_alloc_mmap(). Avoid integer division in choose_arena() for the NO_TLS case on single-CPU systems.
* set WARNS to 1: with WARNS=2 an aliasing error in a file generated bymatteo2008-02-051-1/+1
| | | | | | | rpcgen from include/rpcsvc/rex.x is exposed and I really don't know how to fix it. MFC after: 1 week
* Document the return type for gelf_fsize(3).jkoshy2008-02-041-1/+2
| | | | Submitted by: kaiw
* After careful consideration (and a brief discussion with attilio@), changedes2008-02-041-1/+1
| | | | | | | | | the semantics of pthread_mutex_islocked_np() to return true if and only if the mutex is held by the current thread. Obviously, change the regression test to match. MFC after: 2 weeks
* Fix incorrect handling of malloc failuresmatteo2008-02-042-2/+8
| | | | | PR: bin/83369 MFC after: 1 week
* Add pthread_mutex_islocked_np(), a cheap way to verify that a mutex isdes2008-02-032-0/+31
| | | | | | | locked. This is intended primarily to support the userland equivalent of the various *_ASSERT_LOCKED() macros we have in the kernel. MFC after: 2 weeks
* Remove incomplete support of AI_ALL and AI_V4MAPPED.ume2008-02-031-21/+0
| | | | Reported by: "Heiko Wundram (Beenic)" <wundram__at__beenic.net>
OpenPOWER on IntegriCloud