summaryrefslogtreecommitdiffstats
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Give sendfile(2) a SF_SYNC flag which makes it wait until all mbufsphk2008-02-031-1/+14
| | | | | | | | referencing the files VM pages are returned from the network stack, making changes to the file safe. This flag does not guarantee that the data has been transmitted to the other end.
* Correct a typo.jkoshy2008-02-031-1/+1
|
* When reinitializing a lockuser, don't assume that the lock is indeischen2008-01-311-7/+15
| | | | | | | | | use. If it is in use, use the watched request, otherwise use the lockuser's own request. Only allocate a lockuser request if both requests are null. PR: 119920 Tested by (6.x): Landon Fuller <landonf -at- bikemonkey -dot- org>
* The devstat(3) manpage claims that only <devstat.h> is needed as ajhb2008-01-311-0/+1
| | | | | | | | | prerequisite for using this interface. However, the 'statinfo' struct actually references CPUSTATES from <sys/resource.h>, so in fact it requires <sys/resource.h> to compile. Use a nested include of <sys/resource.h> to make the code match the docs. Reported by: Pietro Cerutti gahr | gahr.ch
* Add hook routine archive_write_ar_finish() which writes the 'ar'kaiw2008-01-311-1/+19
| | | | | | | | | | | | | | | | | | | global header if nothing else has been written before the closing of the archive. This will change the behaviour when creating archives without members, i.e., instead of generating a 0-size archive file, an archive with just the global header (8 bytes in total) will be created and it is indeed a valid archive by the definition of libarchive, thus subsequent operation on this archive will be accepted. This especially solves the failure caused by following sequence: (several ports do) % ar cru libfoo.a # without specifying obj files % ranlib libfoo.a Reviewed by: kientzle, jkoshy Approved by: kientzle Approved by: jkoshy (mentor) Reported by: erwin MFC after: 1 month
* Add a test to verify compatibility with archives withkientzle2008-01-313-0/+145
| | | | | odd hardlinks. I need to extend this to test pax extended archives with bodies attached to hardlinks and other less-common cases.
* Tighten up the heuristic that decides whether or not we shouldkientzle2008-01-311-20/+36
| | | | | | | | | | | obey or ignore the size field on a hardlink entry. In particular, if we're reading a non-POSIX archive, we should always ignore the size field. This should fix both the audio/xmcd port and the math/unixstat port. Thanks to: Pav Lucistnik for pointing these two ports out to me. MFC after: 7 days
* Update this manual page to describe the extattr_list_file() and thetrhodes2008-01-291-6/+13
| | | | | | | | extattr_list_fd() functions. PR: 108142 Submitted by: Richard Dawe <rich@phekda.gotadsl.co.uk> Reviewed by: kientzle
* Adjust the exponent before converting the result from double todas2008-01-281-16/+10
| | | | | float precision. This fixes some double rounding problems for subnormals and simplifies things a bit.
* Our fts(3) API, as inherited from 4.4BSD, suffers from integeryar2008-01-266-93/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fields in FTS and FTSENT structs being too narrow. In addition, the narrow types creep from there into fts.c. As a result, fts(3) consumers, e.g., find(1) or rm(1), can't handle file trees an ordinary user can create, which can have security implications. To fix the historic implementation of fts(3), OpenBSD and NetBSD have already changed <fts.h> in somewhat incompatible ways, so we are free to do so, too. This change is a superset of changes from the other BSDs with a few more improvements. It doesn't touch fts(3) functionality; it just extends integer types used by it to match modern reality and the C standard. Here are its points: o For C object sizes, use size_t unless it's 100% certain that the object will be really small. (Note that fts(3) can construct pathnames _much_ longer than PATH_MAX for its consumers.) o Avoid the short types because on modern platforms using them results in larger and slower code. Change shorts to ints as follows: - For variables than count simple, limited things like states, use plain vanilla `int' as it's the type of choice in C. - For a limited number of bit flags use `unsigned' because signed bit-wise operations are implementation-defined, i.e., unportable, in C. o For things that should be at least 64 bits wide, use long long and not int64_t, as the latter is an optional type. See FTSENT.fts_number aka FTS.fts_bignum. Extending fts_number `to satisfy future needs' is pointless because there is fts_pointer, which can be used to link to arbitrary data from an FTSENT. However, there already are fts(3) consumers that require fts_number, or fts_bignum, have at least 64 bits in it, so we must allow for them. o For the tree depth, use `long'. This is a trade-off between making this field too wide and allowing for 64-bit inode numbers and/or chain-mounted filesystems. On the one hand, `long' is almost enough for 32-bit filesystems on a 32-bit platform (our ino_t is uint32_t now). On the other hand, platforms with a 64-bit (or wider) `long' will be ready for 64-bit inode numbers, as well as for several 32-bit filesystems mounted one under another. Note that fts_level has to be signed because -1 is a magic value for it, FTS_ROOTPARENTLEVEL. o For the `nlinks' local var in fts_build(), use `long'. The logic in fts_build() requires that `nlinks' be signed, but our nlink_t currently is uint16_t. Therefore let's make the signed var wide enough to be able to represent 2^16-1 in pure C99, and even 2^32-1 on a 64-bit platform. Perhaps the logic should be changed just to use nlink_t, but it can be done later w/o breaking fts(3) ABI any more because `nlinks' is just a local var. This commit also inludes supporting stuff for the fts change: o Preserve the old versions of fts(3) functions through libc symbol versioning because the old versions appeared in all our former releases. o Bump __FreeBSD_version just in case. There is a small chance that some ill-written 3-rd party apps may fail to build or work correctly if compiled after this change. o Update the fts(3) manpage accordingly. In particular, remove references to fts_bignum, which was a FreeBSD-specific hack to work around the too narrow types of FTSENT members. Now fts_number is at least 64 bits wide (long long) and fts_bignum is an undocumented alias for fts_number kept around for compatibility reasons. According to Google Code Search, the only big consumers of fts_bignum are in our own source tree, so they can be fixed easily to use fts_number. o Mention the change in src/UPDATING. PR: bin/104458 Approved by: re (quite a while ago) Discussed with: deischen (the symbol versioning part) Reviewed by: -arch (mostly silence); das (generally OK, but we didn't agree on some types used; assuming that no objections on -arch let me to stick to my opinion)
* Fix a harmless type error in 1.9.bde2008-01-251-1/+1
|
* Fix a regression introduced in rev 1.99: replace fclose(f) with a commentdes2008-01-231-1/+5
| | | | | | explaining why f cannot possibly be a valid FILE * at this point. MFC after: 1 day
* Track version # from the portable release.kientzle2008-01-231-1/+1
|
OpenPOWER on IntegriCloud