Commit Graph

10087 Commits

Author SHA1 Message Date
Doug Rabson
0606b9944a Use the correct shared-library version number (the same as the one used
by the standalone version of heimdal GSS-API). If any compat issues
arise, I may increment the version number once more.
2006-01-01 11:01:01 +00:00
Christian S.J. Peron
111a16a8ee Document the LOGIN_SETMAC setusercontext(3) flag. While we are here, drop
in an external reference to mac_set_proc(3).
2005-12-30 06:16:20 +00:00
Doug Rabson
c0b9f4fe65 Add a new extensible GSS-API layer which can support GSS-API plugins,
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)
2005-12-29 14:40:22 +00:00
Doug Barton
a52821c94c Updated versions of header files generated per the instructions
in src/contrib/bind9/FREEBSD-Upgrade for the 9.2.3 import
2005-12-29 04:29:03 +00:00
Peter Grehan
ec9cc1fc12 gmon now supported on powerpc 2005-12-29 04:10:52 +00:00
Peter Grehan
7d65909eed The minbrk symbol is hidden the same on powerpc as other FreeBSD platforms. 2005-12-29 04:09:38 +00:00
Tom Rhodes
257551c6a0 Add a64l(), l64a(), and l64a_r() XSI extentions. These functions convert
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
2005-12-24 22:37:59 +00:00
Poul-Henning Kamp
4c13606d1e Add abort2 manual page.
Submitted by:	"Wojciech A. Koszek" <dunstan@freebsd.czest.pl>
Edited by:	phk
2005-12-23 12:27:42 +00:00
Olivier Houchard
80c276c1f5 Explicitely use a "signed char" instead of a "char", for those archs where
char defaults to unsigned.
2005-12-22 14:23:54 +00:00
David Xu
e6262545cf Let _mutex_cv_lock call internal functiona mutex_lock_common. 2005-12-21 05:14:07 +00:00
David Xu
8429e73473 Hide umtx API symbols as well. 2005-12-21 03:53:29 +00:00
David Xu
cf905a1575 1. Retire macro SCLASS, instead simply use language keyword and
put variables in thr_init.c.
2. Hide all global symbols which won't be exported.
2005-12-21 03:14:06 +00:00
David Xu
7a65760923 Follow the mistake in libpthread, the first version name in libpthread
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).
2005-12-21 02:34:20 +00:00
Bruce Evans
5776f433ab Extract the high and low words together. With gcc-3.4 on uniformly
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.
2005-12-20 01:21:30 +00:00
David Xu
597dc824a0 Clear return code to zero if joiner successfully waited joinee.
Bug reported by: jasone at connonware when using ports lang/onyx
MFC after: 3 days
2005-12-19 03:20:55 +00:00
Bruce Evans
c5964538b7 Use a minimax polynomial approximation instead of a Pade rational
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).
2005-12-19 00:22:03 +00:00
Bruce Evans
ce804bff58 Fixed code to match comments and the algorithm:
- 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.
2005-12-18 21:46:47 +00:00
Alexander Kabaev
0eb88f2029 Implement ELF symbol versioning using GNU semantics. This code aims
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.
2005-12-18 19:43:33 +00:00
Marcel Moolenaar
757686b115 Make our ELF64 type definitions match standards. In particular this
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
2005-12-18 04:52:37 +00:00
David Xu
df2cf82178 Update copyright. 2005-12-17 09:42:45 +00:00
Poul-Henning Kamp
75067f4f70 Add an extensible version of our *printf(3) implementation to libc
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.
2005-12-16 18:56:39 +00:00
David Xu
3b52e4d1b7 With current pthread implementations, a mutex initialization will
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
2005-12-16 02:50:53 +00:00
Bruce Evans
7aac169e18 Added comments about the apparently-magic rational function used in
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.
2005-12-15 16:23:22 +00:00
Bruce Evans
ec761d7501 Optimize by not doing excessive conversions for handling the sign bit.
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.
2005-12-13 20:17:23 +00:00
Bruce Evans
7d5a4821ba Fixed some especially horrible style bugs (indentation that is neither
KNF nor fdlibmNF combined with multiple statements per line).
2005-12-13 18:22:00 +00:00
Ruslan Ermilov
a5b0d9050a [mdoc] add missing space before a punctuation type argument. 2005-12-13 17:07:52 +00:00
David Xu
412295fdbd Sort .Xr by section number.
Submitted by: ru
2005-12-13 13:43:35 +00:00
Poul-Henning Kamp
b384108ed6 /* You're not supposed to hit this problem */
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@
2005-12-13 13:23:27 +00:00
David Xu
e9e7495667 Add cross references to siginfo.3. 2005-12-13 03:05:58 +00:00
David Xu
e6a9baa280 Remove unused _get_curthread() call. 2005-12-12 07:14:57 +00:00
Bruce Evans
af7f99131d Added comments about the magic behind
<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).
2005-12-11 19:51:30 +00:00
Bruce Evans
288a8c86cb Fixed the unexpectedly large maximum error after the previous commit.
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).
2005-12-11 17:58:14 +00:00
Bruce Evans
6de073b4ef Fixed all 502518670 errors of more than 1 ulp for cbrtf() on amd64.
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.)
2005-12-11 13:22:01 +00:00
Bruce Evans
1a787460ba Fixed some magic numbers.
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.
2005-12-11 11:40:55 +00:00
David E. O'Brien
9b39b7cba6 "Create" ldexpf for non-i386 architectures.
Submitted by:	Steve Kargl <sgk@troutmask.apl.washington.edu>
2005-12-06 20:12:38 +00:00
David Xu
f2a77c2a7c Fix markeup.
Submitted by: ru
2005-12-06 09:52:54 +00:00
David Xu
52cf88e2ef Fix markup.
Submitted by: ru
2005-12-05 09:31:49 +00:00
David Xu
8c1e5ef215 Document SIGEV_NONE and SIGEV_SIGNAL. 2005-12-05 04:44:39 +00:00
Bruce Evans
0f06be5a4d Fixed the approximation to pio4. pio4_hi must be pio2_hi/2 since it
shares its low half with pio2_hi.  pio2_hi is rounded down although
rounding to nearest would be a tiny bit better, so pio4_hi must be
rounded down too.  It was rounded to nearest, which happens to be
different in float precision but the same in double precision.

This fixes about 13.5 million errors of more than 1 ulp in asinf().
The largest error was 2.81 ulps on amd64 and 2.57 ulps on i386 -O1.
Now the largest error is 0.93 ulps on amd65 and 0.67 ulps on i386 -O1.
2005-12-04 13:52:46 +00:00
Bruce Evans
d48ea9753c For log1pf(), fixed the approximations to sqrt(2), sqrt(2)-1 and
sqrt(2)/2-1.  For log1p(), fixed the approximation to sqrt(2)/2-1.

The end result is to fix an error of 1.293 ulps in
    log1pf(0.41421395540 (hex 0x3ed413da))
and an error of 1.783 ulps in
    log1p(-0.292893409729003961761) (hex 0x12bec4 00000001)).
The former was the only error of > 1 ulp for log1pf() and the latter
is the only such error that I know of for log1p().

The approximations don't need to be very accurate, but the last 2 need
to be related to the first and be rounded up a little (even more than
1 ulp for sqrt(2)/2-1) for the following implementation-detail reason:
when the arg (x) is not between (the approximations to) sqrt(2)/2-1
and sqrt(2)-1, we commit to using a correction term, but we only
actually use it if 1+x is between sqrt(2)/2 and sqrt(2) according to
the first approximation. Thus we must ensure that
!(sqrt(2)/2-1 < x < sqrt(2)-1) implies !(sqrt(2)/2 < x+1 < sqrt(2)),
where all the sqrt(2)'s are really slightly different approximations
to sqrt(2) and some of the "<"'s are really "<="'s.  This was not done.

In log1pf(), the last 2 approximations were rounded up by about 6 ulps
more than needed relative to a good approximation to sqrt(2), but the
actual approximation to sqrt(2) was off by 3 ulps.  The approximation
to sqrt(2)-1 ended up being 4 ulps too small, so the algoritm was
broken in 4 cases.  The result happened to be broken in 1 case.  This
is fixed by using a natural approximation to sqrt(2) and derived
approximations for the others.

In logf(), all the approximations made sense, but the approximation
to sqrt(2)/2-1 was 2 ulps too small (a tiny amount, since we compare
with a granularity of 2**32 ulps), so the algorithm was broken in 2
cases.  The result was broken in 1 case.  This is fixed by rounding
up the approximation to sqrt(2)/2-1 by 2**32 ulps, so 2**32 cases are
now handled a little differently (still correctly according to my
assertion that the approximations don't need to be very accurate, but
this has not been checked).
2005-12-04 12:30:44 +00:00
Stefan Farfeleder
2c05ef0cff Merge NetBSD's revision 1.27. This bug can be observed eg. when browsing
through the history in sh.

| Refresh bug reported by Julien Torres:
|
| going from:
|     activate -verbose
| to:
|     reset -activation
| results in:
|     reset -activationverbose"
| instead of:
|     reset -activation
|
| This is because we choose to insert "reset -" before the current line,
| and the delete "e -" and insert "ion" in the appropriate place. The
| cleareol code did not handle this case properly; we now cleareol to
| the maximum number of characters of the first difference, the second
| difference and the difference in line length.
2005-12-04 09:34:56 +00:00
Bruce Evans
669152498a Use the usual volatile hack to trick gcc into clipping any extra precision
on assignment.

Extra precision on i386's broke hi+lo decomposition in the usual way.
It caused all except 1 of the 62343 errors of more than 1 ulp for
log1pf() on i386's with gcc -O [-fno-float-store].
2005-12-04 08:57:54 +00:00
Bruce Evans
00b1756b1e Fixed fdlibm[+cygnus] logbf() and logb() on denormals. Adjustment
according to the highest nonzero bit in a denormal was missing.

fdlibm ilogbf() and ilogb() have always had the adjustment, but only
use a small part of their method for handling denormals; use the
normalization method in log[f]() for the main part.
2005-12-03 11:57:19 +00:00
Ruslan Ermilov
4b66957aa4 Fix prototype. 2005-12-03 09:01:02 +00:00
Ruslan Ermilov
fc37aef9c0 Fix type of argument. 2005-12-03 09:00:43 +00:00
Bruce Evans
1186054263 Restored removal of the special handling needed for a result of +-0.
It was lost in rev.1.9.  The log message for rev.1.9 says that the
special case of +-0 is handled twice, but it was only handled once,
so it became unhandled, and this happened to break half of the cases
that return +-0:
- round-towards-minus-infinity:  0   <  x < 1:  result was -0 not  0
- round-to-nearest:             -0.5 <= x < 0:  result was  0 not -0
- round-towards-plus-infinity:  -1   <  x < 0:  result was  0 not -0
- round-towards-zero:           -1   <  x < 0:  result was  0 not -0
2005-12-03 09:00:29 +00:00
Ruslan Ermilov
61df86c1ed Break hard sentence break. 2005-12-03 08:52:07 +00:00
Bruce Evans
3fc5a433e9 Simplified the fix in rev.1.3. Instead of using long double for
TWO52[sx] to trick gcc into correctly converting TWO52[sx]+x to double
on assignment to "double w", force a correct assignment by assigning
to *(double *)&w.  This is cleaner and avoids the double rounding
problem on machines that evaluate double expressions in double
precision.  It is not necessary to convert w-TWO52[sx] to double
precision on return as implied in the comment in rev.1.3, since
the difference is exact.
2005-12-03 07:38:35 +00:00
Bruce Evans
7441377544 Fixed rint(x) in the following cases:
(1) In round-to-nearest mode, on all machines, fdlibm rint() never
    worked for |x| = n+0.75 where n is an even integer between 262144
    and 524286 inclusive (2*131072 cases).  To avoid double rounding
    on some machines, we begin by adjusting x to a value with the 0.25
    bit not set, essentially by moving the 0.25 bit to a lower bit
    where it works well enough as a guard, but we botched the adjustment
    when log2(|x|) == 18 (2*2**52 cases) and ended up just clearing
    the 0.25 bit then.  Most subcases still worked accidentally since
    another lower bit serves as a guard.  The case of odd n worked
    accidentally because the rounding goes the right way then.  However,
    for even n, after mangling n+0.75 to 0.5, rounding gives n but the
    correct result is n+1.
(2) In round-towards-minus-infinity mode, on all machines, fdlibm rint()
    never for x = n+0.25 where n is any integer between -524287 and
    -262144 inclusive (262144 cases).  In these cases, after mangling
    n+0.25 to n, rounding gives n but the correct result is n-1.
(3) In round-towards-plus-infinity mode, on all machines, fdlibm rint()
    never for x = n+0.25 where n is any integer between 262144 and
    524287 inclusive (262144 cases).  In these cases, after mangling
    n+0.25 to n, rounding gives n but the correct result is n+1.

A variant of this bug was fixed for the float case in rev.1.9 of s_rintf.c,
but the analysis there is incomplete (it only mentions (1)) and the fix
is buggy.

Example of the problem with double rounding: rint(1.375) on a machine
which evaluates double expressions with just 1 bit of extra precision
and is in round-to-nearest mode.  We evaluate the result using
(double)(2**52 + 1.375) - 2**52.  Evaluating 2**52 + 1.375 in (53+1) bit
prcision gives 2**52 + 1.5 (first rounding).  (Second) rounding of this
to double gives 2**52 + 2.0.  Subtracting 2**52 from this gives 2.0 but
we want 1.0.  Evaluating 2**52 + 1.375 in double precision would have
given the desired intermediate result of 2**52 + 1.0.

The double rounding problem is relatively rare, so the botched adjustment
can be fixed for most machines by removing the entire adjustment.  This
would be a wrong fix (using it is 1 of the bugs in rev.1.9 of s_rintf.c)
since fdlibm is supposed to be generic, but it works in the following cases:
- on all machines that evaluate double expressions in double precision,
  provided either long double has the same precision as double (alpha,
  and i386's with precision forced to double) or my earlier fix to use
  a long double 2**52 is modified to avoid using long double precision.
- on all machines that evaluate double expressions in many more than 11
  bits of extra precision.  The 1 bit of extra precision in the example
  is the worst case.  With N bits of extra precision, it sufices to
  adjust the bit N bits below the 0.5 bit.  For N >= about 52 there is
  no such bit so the adjustment is both impossible and unnecessary.  The
  fix in rev.1.9 of s_rintf.c apparently depends on corresponding magic
  in float precision: on all supported machines N is either 0 or >= 24,
  so double rounding doesn't occur in practice.
- on all machines that don't use fdlibm rint*() (i386's).
So under FreeBSD, the double rounding problem only affects amd64 now, but
should only affect i386 in future (when double expressions are evaluated
in long double precision).
2005-12-03 07:23:30 +00:00
Doug Ambrisko
c26efd485e Switch BUILD_ARCH in Makefile to use uname -p suggested by ru.
Switch strncpy to strlcpy suggested by gad and issue found by pjd.
Add to uname(3) man page describing:
	UNAME_s
	UNAME_r
	UNAME_v
	UNAME_m
Add to getosreldate(3) man page describing:
	OSVERSION

Submitted by:	ru, pjd/gad
Reviewed by:	ru (man pages)
2005-12-03 05:11:07 +00:00