summaryrefslogtreecommitdiffstats
path: root/lib
Commit message (Collapse)AuthorAgeFilesLines
* Rescue pthread_set_name_np for compatible reason, remove unused code.davidxu2006-01-092-151/+10
|
* Tweak macro THR_LOCK_RELEASE a bit for non-PTHREAD_INVARIANTS case.davidxu2006-01-091-7/+14
|
* Return real detached state.davidxu2006-01-091-0/+2
|
* Fix a bug recently introduced, the _thread_active_count should bedavidxu2006-01-081-0/+1
| | | | decreased if thread can not be created.
* Allow background threads to be suspended.davidxu2006-01-081-1/+4
|
* Try to reduce total time needed for suspending all threads,davidxu2006-01-081-4/+17
| | | | first broadcast signals to all threads, then enter a wait loop.
* Remove functions i386_get_gsbase and i386_set_gsbase, they were alreadydavidxu2006-01-071-14/+0
| | | | in libc.
* o Document the possibility of putting 'b' in the flag field.ceri2006-01-061-5/+11
| | | | | | | While we don't use the NC_BROADCAST value of nc_flag anywhere in the RPC code, it is parseable by getnetconfigent(3) from /etc/netconfig. o Clean up some "see below"'s that were cut and pasted from netconfig.h.
* Refine thread suspension code, now thread suspension is a blockabledavidxu2006-01-057-68/+177
| | | | | | | operation, the caller is blocked util target threads are really suspended, also avoid suspending a thread when it is holding a critical lock. Fix a bug in _thr_ref_delete which tests a never set flag.
* Oops, on amd64 (and probably on all non-i386 systems), the previousbde2006-01-051-6/+11
| | | | | | | | | | | | | | commit broke the 2**24 cases where |x| > DBL_MAX/2. There are exponent range problems not just for denormals (underflow) but for large values (overflow). Doubles have more than enough exponent range to avoid the problems, but I forgot to convert enough terms to double, so there was an x+x term which was sometimes evaluated in float precision. Unfortunately, this is a pessimization with some combinations of systems and compilers (it makes no difference on Athlon XP's, but on Athlon64's it gives a 5% pessimization with gcc-3.4 but not with gcc-3.3). Exlain the problem better in comments.
* Document the recently-added EINVAL behavior.dds2006-01-051-1/+7
| | | | MFC after: 1 week
* Use double precision internally to optimize cbrtf(), and change thebde2006-01-051-28/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | algorithm for the second step significantly to also get a perfectly rounded result in round-to-nearest mode. The resulting optimization is about 25% on Athlon64's and 30% on Athlon XP's (about 25 cycles out of 100 on the former). Using extra precision, we don't need to do anything special to avoid large rounding errors in the third step (Newton's method), so we can regroup terms to avoid a division, increase clarity, and increase opportunities for parallelism. Rearrangement for parallelism loses the increase in clarity. We end up with the same number of operations but with a division reduced to a multiplication. Using specifically double precision, there is enough extra precision for the third step to give enough precision for perfect rounding to float precision provided the previous steps are accurate to 16 bits. (They were accurate to 12 bits, which was almost minimal for imperfect rounding in the old version but would be more than enough for imperfect rounding in this version (9 bits would be enough now).) I couldn't find any significant time optimizations from optimizing the previous steps, so I decided to optimize for accuracy instead. The second step needed a division although a previous commit optimized it to use a polynomial approximation for its main detail, and this division dominated the time for the second step. Use the same Newton's method for the second step as for the third step since this is insignificantly slower than the division plus the polynomial (now that Newton's method only needs 1 division), significantly more accurate, and simpler. Single precision would be precise enough for the second step, but doesn't have enough exponent range to handle denormals without the special grouping of terms (as in previous versions) that requires another division, so we use double precision for both the second and third steps.
* 1. Add SIGEV_THREAD notification for mq_notify.davidxu2006-01-042-198/+343
| | | | | 2. Reuse current timer code and abstract some common code to to support both timer and mqueue.
* For the ``#ifdef NOTYET'' code that allows calling non-async-safebrian2006-01-032-2/+2
| | | | | | | | | | functions in the child after a fork() from a threaded process, use __sys_setprocmask() rather than setprocmask() to keep our signal handling sane. Without this fix, signals are essentially ignored in said child and things such as protection violations result in an endless busy loop. Reviewed by: deischen
* Remove in-progress wait code to sync with libpthread's behavior.davidxu2006-01-031-30/+8
|
* Use the correct shared-library version number (the same as the one useddfr2006-01-011-1/+1
| | | | | by the standalone version of heimdal GSS-API). If any compat issues arise, I may increment the version number once more.
* Document the LOGIN_SETMAC setusercontext(3) flag. While we are here, dropcsjp2005-12-301-0/+5
| | | | in an external reference to mac_set_proc(3).
* Add a new extensible GSS-API layer which can support GSS-API plugins,dfr2005-12-2986-1/+10705
| | | | | | | | | similar the the Solaris implementation. Repackage the krb5 GSS mechanism as a plugin library for the new implementation. This also includes a comprehensive set of manpages for the GSS-API functions with text mostly taken from the RFC. Reviewed by: Love Hörnquist Åstrand <lha@it.su.se>, ru (build system), des (openssh parts)
* Updated versions of header files generated per the instructionsdougb2005-12-296-14/+61
| | | | in src/contrib/bind9/FREEBSD-Upgrade for the 9.2.3 import
* gmon now supported on powerpcgrehan2005-12-291-2/+0
|
* The minbrk symbol is hidden the same on powerpc as other FreeBSD platforms.grehan2005-12-291-1/+1
|
* Add a64l(), l64a(), and l64a_r() XSI extentions. These functions converttrhodes2005-12-244-5/+290
| | | | | | | | between a 32-bit integer and a radix-64 ASCII string. The l64a_r() function is a NetBSD addition. PR: 51209 (based on submission, but very different) Reviewed by: bde, ru
* Add abort2 manual page.phk2005-12-232-1/+100
| | | | | Submitted by: "Wojciech A. Koszek" <dunstan@freebsd.czest.pl> Edited by: phk
* Explicitely use a "signed char" instead of a "char", for those archs wherecognet2005-12-221-2/+2
| | | | char defaults to unsigned.
* Let _mutex_cv_lock call internal functiona mutex_lock_common.davidxu2005-12-211-1/+2
|
* Hide umtx API symbols as well.davidxu2005-12-212-6/+9
|
* 1. Retire macro SCLASS, instead simply use language keyword anddavidxu2005-12-212-109/+124
| | | | | put variables in thr_init.c. 2. Hide all global symbols which won't be exported.
* Follow the mistake in libpthread, the first version name in libpthreaddavidxu2005-12-211-1/+1
| | | | | | is LIBTHREAD_1_0, but really it should be LIBPTHREAD_1_0. Fix it so libmap.conf works again (it was broken by recent versioning code in rtld_elf).
* Extract the high and low words together. With gcc-3.4 on uniformlybde2005-12-201-8/+6
| | | | | | | | | | | | | | | | | | | | distributed non-large args, this saves about 14 of 134 cycles for Athlon64s and about 5 of 199 cycles for AthlonXPs. Moved the check for x == 0 inside the check for subnormals. With gcc-3.4 on uniformly distributed non-large args, this saves another 5 cycles on Athlon64s and loses 1 cycle on AthlonXPs. Use INSERT_WORDS() and not SET_HIGH_WORD() when converting the first approximation from bits to double. With gcc-3.4 on uniformly distributed non-large args, this saves another 4 cycles on both Athlon64s and and AthlonXPs. Accessing doubles as 2 words may be an optimization on old CPUs, but on current CPUs it tends to cause extra operations and pipeline stalls, especially for writes, even when only 1 of the words needs to be accessed. Removed an unused variable.
* Clear return code to zero if joiner successfully waited joinee.davidxu2005-12-191-0/+1
| | | | | Bug reported by: jasone at connonware when using ports lang/onyx MFC after: 3 days
* Use a minimax polynomial approximation instead of a Pade rationalbde2005-12-192-37/+30
| | | | | | | | | | | | | | | | | function approximation for the second step. The polynomial has degree 2 for cbrtf() and 4 for cbrt(). These degrees are minimal for the final accuracy to be essentially the same as before (slightly smaller). Adjust the rounding between steps 2 and 3 to match. Unfortunately, for cbrt(), this breaks the claimed accuracy slightly although incorrect rounding doesn't. Claim less accuracy since its not worth pessimizing the polynomial or relying on exhaustive testing to get insignificantly more accuracy. This saves about 30 cycles on Athlons (mainly by avoiding 2 divisions) so it gives an overall optimization in the 10-25% range (a larger percentage for float precision, especially in 32-bit mode, since other overheads are more dominant for double precision, surprisingly more in 32-bit mode).
* Fixed code to match comments and the algorithm:bde2005-12-182-20/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - in preparing for the third approximation, actually make t larger in magnitude than cbrt(x). After chopping, t must be incremented by 2 ulps to make it larger, not 1 ulp since chopping can reduce it by almost 1 ulp and it might already be up to half a different-sized-ulp smaller than cbrt(x). I have not found any cases where this is essential, but the think-time error bound depends on it. The relative smallness of the different-sized-ulp limited the bug. If there are cases where this is essential, then the final error bound would be 5/6+epsilon instead of of 4/6+epsilon ulps (still < 1). - in preparing for the third approximation, round more carefully (but still sloppily to avoid branches) so that the claimed error bound of 0.667 ulps is satisfied in all cases tested for cbrt() and remains satisfied in all cases for cbrtf(). There isn't enough spare precision for very sloppy rounding to work: - in cbrt(), even with the inadequate increment, the actual error was 0.6685 in some cases, and correcting the increment increased this a little. The fix uses sloppy rounding to 25 bits instead of very sloppy rounding to 21 bits, and starts using uint64_t instead of 2 words for bit manipulation so that rounding more bits is not much costly. - in cbrtf(), the 0.667 bound was already satisfied even with the inadequate increment, but change the code to almost match cbrt() anyway. There is not enough spare precision in the Newton approximation to double the inadequate increment without exceeding the 0.667 bound, and no spare precision to avoid this problem as in cbrt(). The fix is to round using an increment of 2 smaller-ulps before chopping so that an increment of 1 ulp is enough. In cbrt(), we essentially do the same, but move the chop point so that the increment of 1 is not needed. Fixed comments to match code: - in cbrt(), the second approximation is good to 25 bits, not quite 26 bits. - in cbrt(), don't claim that the second approximation may be implemented in single precision. Single precision cannot handle the full exponent range without minor but pessimal changes to renormalize, and although single precision is enough, 25 bit precision is now claimed and used. Added comments about some of the magic for the error bound 4/6+epsilon. I still don't understand why it is 4/6+ and not 6/6+ ulps. Indent comments at the right of code more consistently.
* Implement ELF symbol versioning using GNU semantics. This code aimskan2005-12-181-0/+9
| | | | | | | | | to be compatible with symbol versioning support as implemented by GNU libc and documented by http://people.redhat.com/~drepper/symbol-versioning and LSB 3.0. Implement dlvsym() function to allow lookups for a specific version of a given symbol.
* Make our ELF64 type definitions match standards. In particular thismarcel2005-12-181-3/+3
| | | | | | | | | | | | | means: o Remove Elf64_Quarter, o Redefine Elf64_Half to be 16-bit, o Redefine Elf64_Word to be 32-bit, o Add Elf64_Xword and Elf64_Sxword for 64-bit entities, o Use Elf_Size in MI code to abstract the difference between Elf32_Word and Elf64_Word. o Add Elf_Ssize as the signed counterpart of Elf_Size. MFC after: 2 weeks
* Update copyright.davidxu2005-12-176-113/+84
|
* Add an extensible version of our *printf(3) implementation to libcphk2005-12-169-0/+2054
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | on probationary terms: it may go away again if it transpires it is a bad idea. This extensible printf version will only be used if either environment variable USE_XPRINTF is defined or one of the extension functions are called. or the global variable __use_xprintf is set greater than zero. In all other cases our traditional printf implementation will be used. The extensible version is slower than the default printf, mostly because less opportunity for combining I/O operation exists when faced with extensions. The default printf on the other hand is a bad case of spaghetti code. The extension API has a GLIBC compatible part and a FreeBSD version of same. The FreeBSD version exists because the GLIBC version may run afoul of our FILE * locking in multithreaded programs and it even further eliminate the opportunities for combining I/O operations. Include three demo extensions which can be enabled if desired: time (%T), hexdump (%H) and strvis (%V). %T can format time_t (%T), struct timeval (%lT) and struct timespec (%llT) in one of two human readable duration formats: "%.3llT" -> "20349.245" "%#.3llT" -> "5h39m9.245" %H will hexdump a sequence of bytes and takes a pointer and a length argument. The width specifies number of bytes per line. "%4H" -> "65 72 20 65" "%+4H" -> "0000 65 72 20 65" "%#4H" -> "65 72 20 65 |er e|" "%+#4H" -> "0000 65 72 20 65 |er e|" %V will dump a string in strvis format. "%V" -> "Hello\tWor\377ld" (C-style) "%0V" -> "Hello\011Wor\377ld" (octal) "%+V" -> "Hello%09Wor%FFld" (http-style) Tests, comments, bugreports etc are most welcome.
* With current pthread implementations, a mutex initialization willdavidxu2005-12-163-9/+19
| | | | | | | | | | | | allocate a memory block. sscanf calls __svfscanf which in turn calls fread, fread triggers mutex initialization but the mutex is not destroyed in sscanf, this leads to memory leak. To avoid the memory leak and performance issue, we create a none MT-safe version of fread: __fread, and instead let __svfscanf call __fread. PR: threads/90392 Patch submitted by: dhartmei MFC after: 7 days
* Added comments about the apparently-magic rational function used inbde2005-12-151-1/+15
| | | | | | | | | | | | | | | | | | | | the second step of approximating cbrt(x). It turns out to be neither very magic not nor very good. It is just the (2,2) Pade approximation to 1/cbrt(r) at r = 1, arranged in a strange way to use fewer operations at a cost of replacing 4 multiplications by 1 division, which is an especially bad tradeoff on machines where some of the multiplications can be done in parallel. A Remez rational approximation would give at least 2 more bits of accuracy, but the (2,2) Pade approximation already gives 6 more bits than needed. (Changed the comment which essentially says that it gives 3 more bits.) Lower order Pade approximations are not quite accurate enough for double precision but are plenty for float precision. A lower order Remez rational approximation might be enough for double precision too. However, rational approximations inherently require an extra division, and polynomial approximations work well for 1/cbrt(r) at r = 1, so I plan to switch to using the latter. There are some technical complications that tend to cost a division in another way.
* Optimize by not doing excessive conversions for handling the sign bit.bde2005-12-132-15/+9
| | | | | | | | | | | | | | | | | | | This gives an optimization of between 9 and 22% on Athlons (largest for cbrt() on amd64 -- from 205 to 159 cycles). We extracted the sign bit and worked with |x|, and restored the sign bit as the last step. We avoided branches to a fault by using accesses to FP values as bits to clear and restore the sign bit. Avoiding branches is usually good, but the bit access macros are not so good (especially for setting FP values), and here they always caused pipeline stalls on Athlons. Even using branches would be faster except on args that give perfect branch misprediction, since only mispredicted branches cause stalls, but it possible to avoid touching the sign bit in FP values at all (except to preserve it in conversions from bits to FP not related to the sign bit). Do this. The results are identical except in 2 of the 3 unsupported rounding modes, since all the approximations use odd rational functions so they work right on strictly negative values, and the special case of -0 doesn't use an approximation.
* Fixed some especially horrible style bugs (indentation that is neitherbde2005-12-132-12/+14
| | | | KNF nor fdlibmNF combined with multiple statements per line).
* [mdoc] add missing space before a punctuation type argument.ru2005-12-131-1/+1
|
* Sort .Xr by section number.davidxu2005-12-138-14/+14
| | | | Submitted by: ru
* /* You're not supposed to hit this problem */phk2005-12-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some denormalized long double values, a bug in __hldtoa() (called from *printf()'s %A format) results in a base 16 digit being rounded up from 0xf to 0x10. When this digit is subsequently converted to string format, an index of 10 reaches past the end of the uppper-case hex/char array, picking up whatever the code segment happen to contain at that address. This mostly seem to be some character from the upper half of the byte range. When using the %a format instead of %A, the first character past the end of the lowercase hex/char table happens to be index 0 in the uppercase hex/char table hextable and therefore the string representation features a '0', which is supposedly correct. This leads me to belive that the proper fix _may_ be as simple as masking all but the lower four bits off after incrementing a hex-digit in libc/gdtoa/_hdtoa.c:roundup(). I worry however that the upper bit in 0x10 indicates a carry not carried. Until das@ or bde@ finds time to visit this issue, extend the hexdigit arrays with a 17th index containing '?' so that we get a invalid but consistent and printable output in both %a and %A formats whenever this bug strikes. This unmasks the bug in the %a format therefore solving the real issue may both become easier and more urgent. Possibly related to: PR 85080 With help by: bde@
* Add cross references to siginfo.3.davidxu2005-12-1310-3/+13
|
* Remove unused _get_curthread() call.davidxu2005-12-121-2/+0
|
* Added comments about the magic behindbde2005-12-112-14/+25
| | | | | | | <cbrt(x) in bits> ~= <x in bits>/3 + BIAS. Keep the large comments only in the double version as usual. Fixed some style bugs (mainly grammar and spelling errors in comments).
* Fixed the unexpectedly large maximum error after the previous commit.bde2005-12-111-2/+2
| | | | | | It was because I forgot to translate the part of the double precision algorithm that chops t so that t*t is exact. Now the maximum error is the same as for double precision (almost exactly 2.0/3 ulps).
* Fixed all 502518670 errors of more than 1 ulp for cbrtf() on amd64.bde2005-12-111-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | The maximum error was 3.56 ulps. The bug was another translation error. The double precision version has a comment saying "new cbrt to 23 bits, may be implemented in precision". This means exactly what it says -- that the 23 bit second approximation for the double precision cbrt() may be implemented in single (i.e., float) precision. It doesn't mean what the translation assumed -- that this approximation, when implemented in float precision, is good enough for the the final approximation in float precision. First, float precision needs a 24 bit approximation. The "23 bit" approximation is actually good to 24 bits on float precision args, but only if it is evaluated in double precision. Second, the algorithm requires a cleanup step to ensure its error bound. In float precision, any reasonable algorithm works for the cleanup step. Use the same algorithm as for double precision, although this is much more than enough and is a significant pessimization, and don't optimize or simplify anything using double precision to implement the float case, so that the whole double precision algorithm can be verified in float precision. A maximum error of 0.667 ulps is claimed for cbrt() and the max for cbrtf() using the same algorithm shouldn't be different, but the actual max for cbrtf() on amd64 is now 0.9834 ulps. (On i386 -O1 the max is 0.5006 (down from < 0.7) due to extra precision.)
* Fixed some magic numbers.bde2005-12-111-8/+8
| | | | | | | | | | | | | | | | | | | | | | The threshold for not being tiny was too small. Use the usual 2**-12 threshold. As for sinhf, use a different method (now the same as for sinhf) to set the inexact flag for tiny nonzero x so that the larger threshold works, although this method is imperfect. As for sinhf, this change is not just an optimization, since the general code that we fell into has accuracy problems even for tiny x. On amd64, avoiding it fixes tanhf on 2*13495596 args with errors of between 1 and 1.3 ulps and thus reduces the total number of args with errors of >= 1 ulp from 37533748 to 5271278; the maximum error is unchanged at 2.2 ulps. The magic number 22 is log(DBL_MAX)/2 plus slop. This is bogus for float precision. Use 9 (log(FLT_MAX)/2 plus less slop than for double precision). Unlike for coshf and tanhf, this is just an optimization, and MAX isn't misspelled EPSILON in the commit log. I started testing with nonstandard rounding modes, and verified that the chosen thresholds work for all modes modulo problems not related to thresholds. The best thresholds are not very dependent on the mode, at least for tanhf.
* "Create" ldexpf for non-i386 architectures.obrien2005-12-061-0/+2
| | | | Submitted by: Steve Kargl <sgk@troutmask.apl.washington.edu>
OpenPOWER on IntegriCloud