Date: Wed, 2 Apr 2003 21:19:21 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/include float.h Message-ID: <20030402203725.O26345@gamplex.bde.org> In-Reply-To: <20030402075905.GA30835@cirb503493.alcatel.com.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030402203725.O26345>