Date: Tue, 29 Oct 2002 05:32:20 -0600 (CST) From: Loren James Rittle <rittle@latour.rsch.comm.mot.com> To: tlambert2@mindspring.com Cc: bde@zeta.org.au, current@freebsd.org, dschultz@uclink.Berkeley.EDU, imp@bsdimp.com Subject: Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol) Message-ID: <200210291132.g9TBWKER074433@latour.rsch.comm.mot.com> In-Reply-To: <3DBE2DA1.62B2563B@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Claiming 53 bits but supporting 64, and then not raising an exception > and/or giving a "NaN" or "INF" result on overflow to the 54th bit is > broken. If you do this, you will fail runtime validation suites. Huh? The 53-bit quantity refers to the mantissa not the exponent. Unless I'm sorely confused, the only IEEE exceptions you could be speaking about is "inexact"; Inf and NaN don't come into play. In any event: As I outlined, in this case (where we advertised 53-bit precision but the user "forced" 64-bit precision - it was not precise for you to use the word "supporting" since that does not characterize the situation I was speaking about properly), the user will have explicitly made a call to change the default precision as conveyed in the system header. At that point, I don't know why the user should be able to expect that the published values in <float.h> are still valid. Do these validation suites typically run with a call to override the precision setting in the IEEE FP control word? Doubtful (or if they do, they know what they are doing; just as application code that monkeys with the control register would have to). I.e. the test suite would be running against the published <limits.h> which at the moment should be: #define LDBL_MANT_DIG 53 #define LDBL_MIN_EXP (-16381) #define LDBL_MAX_EXP 16384 (All other published LDBL_ constants are derivable from these.) since they match the default FP control word setting on FreeBSD/i386. > I don't think that any amount of hand-waving will turn it into a > compiler-only issue. I am not trying to handwave anything. The currently published <float.h> (both before and after recent patch) is what is attempting to handwave something. It doesn't match the hardware settings. That patch it just received fixed one thing (exponent range) but broke another (precision/epsilon). More than anything, I am attempting to have that file written exactly to match the default hardware setup. Since there is exactly one default hardware setup for any particular booted system, it seems possible to do. If I were doing what is claimed, I would have "fixed" the issue in gcc mainline without consulting FreeBSD-side experts. Perhaps we should just leave it broken in the FSF tree and let an "expert" sort it out when they import gcc 3.3 into FreeBSD. However, it seemed reasonable to me to fix the issues exposed by the gcc infrastructure change ASAP... > I'd like to see Bruce's issues with the 64 bit support taken care > of with long double (and the implicit cast that occurs in the one > case that Bruce complained about in his email, where there is *too > much* precision on the rvalue, which is a computation of dobule > operands done in long double form, with a double result). I think I now understand Bruce's point. There are two issues: (a) incorrect double-rounding (once to the precision of extended double in register and another to double when moved to memory allocated for double); (b) non-exact comparisons where might otherwise be expected by programmers even if not absolutely guaranteed by IEEE 754. To anyone that wishes to understand it, start reading page 249 of this version of _What Every Computer Scientist Should Know About Floating-Point Arithmetic_ http://www.validlab.com/goldberg/paper.ps FYI, by default, FreeBSD/i386 uses technique 4 on page 260 to circumvent these issues. (There is a proof earlier that fully explains why double-rounding doesn't affect double->float conversions on i386.) Now, in case anyone cares, gcc 3.3 will expose the C99 FLT_EVAL_METHOD macro (set to 2 for FreeBSD/i386) and related float_t and double_t types (which will both map to long double to represent the destination of intermediate results otherwise beyond the user's control). Given the extended range of the exponent of a double or float in an i386 HW FP register; I believe that is correct. Regards, Loren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210291132.g9TBWKER074433>