From owner-cvs-all@FreeBSD.ORG Wed Apr 2 03:19:44 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BED937B401; Wed, 2 Apr 2003 03:19:44 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7274743F85; Wed, 2 Apr 2003 03:19:42 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA26502; Wed, 2 Apr 2003 21:19:22 +1000 Date: Wed, 2 Apr 2003 21:19:21 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Peter Jeremy In-Reply-To: <20030402075905.GA30835@cirb503493.alcatel.com.au> Message-ID: <20030402203725.O26345@gamplex.bde.org> References: <200303272038.h2RKcM7L096560@repoman.freebsd.org> <20030330175646.281097ad.Alexander@Leidinger.net> <20030331082023.GE11307@cirb503493.alcatel.com.au> <20030401172440.701aaafd.Alexander@Leidinger.net> <20030402154250.X25489@gamplex.bde.org> <20030402075905.GA30835@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Alexander Leidinger cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/include float.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2003 11:19:44 -0000 On Wed, 2 Apr 2003, Peter Jeremy wrote: > On Wed, Apr 02, 2003 at 04:21:30PM +1000, Bruce Evans wrote: > >On Wed, 2 Apr 2003, Peter Jeremy wrote: > > > >> On Tue, Apr 01, 2003 at 05:24:40PM +0200, Alexander Leidinger wrote: > >> >We noticed that icc does use other values for LDBL_MIN than we do, and > >> >instead of just thinking that Intel does it right I wanted to verify it. > > > >This might be caused by icc actually understanding the target's default > >precision for long doubles (FreeBSD changes the hardware default of 64-bit > >to 53-bit for technical reasons). > > Is this also true on ia64? Probably not. ia64's _fpmath.h says that there are 64 mantissa bits, and we don't reduce the precision AFAIK. > And the LDBL_* constants for sparc64 are > for 113-bit fractions. I was going to mention this but thought it had > changed since all the LDBL_* constants have been changed to 64-bit > fraction values (they are 53-bit in -STABLE). sparc64's _fpmath.h says that long doubles have a full 128 bits with 112 mantissa bits, so 113-bit fractions are possible (with an implicit normalization bit). > Which is more wrong: LDBL_* constants that are "correct" but unusable > because the CPU is set to "round to double" or LBDL_* constants that > match the CPU rounding but not the compiler's "long double" type? precision, actually The latter. It's a compiler bug that the compiler's "long double" type doesn't match the hardware (as configured). Differences in rounding cause the same sort or problems and is more important in practice -- C99 has a lot to say about how much the compiler can assume about the runtime rounding matches the compile time rounding (this affects constant folding), but it doesn't say anything about changing the precision at runtime because changing the precision is not very useful and not supported. > >ucbtest is good but is too old to cover much of C99. I haven't found > >anything anywhere near as good and up to date. > > I was also thinking of paranoia - which has been imported into gcc > as enquire. It's even older than ucbtest and does a good job of > generating all the float.h constants - but it doesn't check that > the CPU actually implements IEEE arithmetic correctly. enquire is different from paranioa. paranoia is even older. I first learned about precision problems running paranoia about 15 years ago and enquire a year two so later. 53-bit bit precision "fixes" the problems reported by paranioa but confuses enquire. With 64-bit precision, paranioa compiled with gcc fails for the same reasons (compiler bugfeatures which exploit the fuzziness of floating point in pre-C99 versions of C to get faster code) as it did 15 years ago: %%% --- paranoia-53bitprecision.out Wed Apr 2 21:02:37 2003 +++ paranoia-64bitprecision.out Wed Apr 2 21:02:42 2003 @@ -97,4 +97,8 @@ Radix confirmed. The number of significant digits of the Radix is 53.000000 . +Some subexpressions appear to be calculated extra +precisely with about 11 extra B-digits, i.e. +roughly 3.31133 extra significant decimals. +That feature is not tested further by this program. To continue, press RETURN @@ -109,9 +113,10 @@ Checking rounding on multiply, divide and add/subtract. -Multiplication appears to round correctly. -Division appears to round correctly. -Addition/Subtraction appears to round correctly. -Checking for sticky bit. -Sticky bit apparently used correctly. +* is neither chopped nor correctly rounded. +/ is neither chopped nor correctly rounded. +Addition/Subtraction neither rounds nor chops. +Sticky bit used incorrectly or not at all. +FLAW: lack(s) of guard digits or failure(s) to correctly round or chop +(noted above) count as one flaw in the final tally below. Does Multiplication commute? Testing on 20 random pairs. @@ -123,5 +128,6 @@ sqrt has passed a test for Monotonicity. Testing whether sqrt is rounded or chopped. -Square root appears to be correctly rounded. +Square root is neither chopped nor correctly rounded. +Observed errors run from -5.0000000e-01 to 5.0000000e-01 ulps. To continue, press RETURN @@ -183,8 +189,6 @@ +The number of FLAWs discovered = 1. -No failures, defects nor flaws have been discovered. -Rounding appears to conform to the proposed IEEE standard P754, -except for possibly Double Rounding during Gradual Underflow. -The arithmetic diagnosed appears to be Excellent! +The arithmetic diagnosed seems Satisfactory though flawed. END OF TEST. %%% This is with a version of paranoia.c dated Apr 16 1988. ucbtest forces 53-bit precision to to avoid these problems. It detects just a couple of the rounding problems (ones related to double rounding -- IIRC the i387 does everything in 64-bit precision, including rounding to that precision; then, if the control word specifies a precision of 53 bits, it rounds to 53 bits. This double rounding can cause 1-bit errors). Bruce