Date: Sat, 8 Feb 2003 21:03:30 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: Mike Barcroft <mike@FreeBSD.ORG>, <standards@FreeBSD.ORG> Subject: Re: fpclassify() for review Message-ID: <20030208201529.E16550-100000@gamplex.bde.org> In-Reply-To: <200302071825.h17IP4s7081758@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 Feb 2003, Garrett Wollman wrote: > I think that, if we had some help from the compiler, it ought to be > possible to implement FLT_EVAL_METHOD == 2 for i386, and that's > probably the closest to the actual hardware implementation. Something This is intentionally not done. i386.md intentionally claims that the hardware implements method 0 (float + float -> float, etc.). This is a bad efficiency hack. Since the hardware actually implements float + float -> pseudo-float := <long double with precision clipped to the current precision>, etc., this gives various bugs. The bugs are intentionally reduced by changing the precision from its hardware default of 64 bits to 53 bits. > similar to Kahan's PARANOIA ought to be able to distinguish the > various methods and thereby serve as a regression test. gcc/enquire.c is better for this. PARANIOA is better for detecting broken clipping of excess precision. Both ENQUIRE and PARANOIA are sensitive to precision, but PARANIOA expects precision errors to some extent so the errors are easier to isolate. Changing the FreeBSD default back to the hardware default causes the following regressions in PARANOIA output: %%% --- paranonia-53bitprecision.out Sat Feb 8 20:42:54 2003 +++ paranonia-64bitprecision.out Sat Feb 8 20:42:50 2003 @@ -98,2 +98,6 @@ 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. @@ -110,7 +114,8 @@ 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. @@ -124,3 +129,4 @@ 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. @@ -184,7 +190,5 @@ +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 1988 version of paranoia.c. The gcc bugs are at least as old. Note that the bug is not extra precision; it is misimplementation of extra precision. PARANIOA understands extra precision and assigns the results of expressions to variables to get rid of it, but gcc doesn't perform the necessary conversions for these assignments because of the hacks in i386.md. PARANIOA works right when compiled with -ffloat-store since it doesn't trust casts and always uses assignments to clip the extra precision. Casts and assignments are supposed to cause the same conversions, but the -ffloat-store hack only works for assignments. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030208201529.E16550-100000>