From owner-freebsd-current Mon Oct 28 18:12:32 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3208E37B401 for ; Mon, 28 Oct 2002 18:12:30 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B95843E6E for ; Mon, 28 Oct 2002 18:12:29 -0800 (PST) (envelope-from rittle@latour.rsch.comm.mot.com) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id TAA24496; Mon, 28 Oct 2002 19:12:28 -0700 (MST)] Received: [from latour.rsch.comm.mot.com (latour.rsch.comm.mot.com [145.1.80.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id TAA29565; Mon, 28 Oct 2002 19:12:27 -0700 (MST)] Received: from latour.rsch.comm.mot.com (localhost.rsch.comm.mot.com [127.0.0.1]) by latour.rsch.comm.mot.com (8.12.6/8.12.6) with ESMTP id g9T2BBpZ010115; Mon, 28 Oct 2002 20:11:11 -0600 (CST) (envelope-from rittle@latour.rsch.comm.mot.com) Received: (from rittle@localhost) by latour.rsch.comm.mot.com (8.12.6/8.12.6/Submit) id g9T2BBcP010112; Mon, 28 Oct 2002 20:11:11 -0600 (CST) Date: Mon, 28 Oct 2002 20:11:11 -0600 (CST) From: Loren James Rittle Message-Id: <200210290211.g9T2BBcP010112@latour.rsch.comm.mot.com> To: current@freebsd.org Cc: bde@zeta.org.au, imp@bsdimp.com, dschultz@uclink.Berkeley.EDU In-reply-to: <20021025182223.D3076-100000@gamplex.bde.org> (message from Bruce Evans on Fri, 25 Oct 2002 19:01:12 +1000 (EST)) Subject: Re: Lack of real long double support (was Re: libstdc++ does not contain fabsl symbol) Reply-To: rittle@labs.mot.com References: <20021025182223.D3076-100000@gamplex.bde.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <20021025182223.D3076-100000@gamplex.bde.org>, Bruce Evans writes: >> If you really want, I can tell RTH that FreeBSD/i386 absolutely wants >> `long double' to be: >> 53 mantissa bits >> 1024 max exponent > No need. I prefer to keep the 53-bit precision for now, but fix the > exponents. OK. This was the resolution that made sense to us on the gcc side (RTH, quickly; myself, some time to get up to speed). FYI, the system header patch that was actually checked in claims 64-bit precision. Oh well, at least the exponents are now correct. ;-) FYI, here is the exact test case which shows the new value for LDBL_EPSILON (derived directly from LDBL_MANT_DIG) is wrong verses the hardware default: #include // Force run-time computation of math (beware, inlining oneld will defeat this). long double oneld() { return 1.0L; } main () { long double a = oneld(); long double b = oneld() + LDBL_EPSILON; if (a == b) abort (); } On ref5 against gcc 3.2.X (as installed as system compiler), with the latest , it crashes. By specification, this is one FP test involving exact equality that is guaranteed to work (and report false, in this case). > Hopefully the precision won't be hard-coded into gcc in such > a way as to completely break changing the precision at runtime. I think > it should affect (only) constant folding. The issues are very similar > to the ones with changing the rounding mode at runtime (C99 compilers > shouldn't do constant folding in "#pragma STDC FENV_ACCESS ON" sections > if the correct result might depend on the FP environment). This exchange has been quite useful. I see that issue. Unfortunately, changing precision of the FP hardware would seem to change the value of epsilon that is exported, both in classic C headers and C++ (the latter being how I originally took any interest in this matter since a C++ test case started failing after the new real.c code was installed). gcc 3.3 will support a framework in which such changes would be easy to convey at compile-time but, to my knowledge, there is no support yet to obtain e.g. the precision setting at run-time. I.e. is now completely dynamically created at compile-time based on the exact knowledge within gcc of the FP hardware; but it is static w.r.t. eventual run-time. It does not know how to effectively export a function ala FreeBSD/alpha's : #define FLT_ROUNDS __flt_rounds() One issue, the standard says that various macros related to float limits are constant expressions (as may be used to influence the preprocessor?). The above construct doesn't conform but I understand the intent. I will advise RTH about that type of issue. Fortunately, in this case, I think advertising 53-bit precision but really using 64-bit precision (i.e. application code overrode system default) doesn't invalidate the advertised epsilon, in terms of how it is used by the application. More generally, I will ask if gcc can support these details as gained from the run-time environment instead of hard-coded defaults. This would be useful for all free OSes not just FreeBSD running on hardware with such "flexible" FP hardware. Any more comments, before I start work on the gcc mainline side of things? Thanks, Loren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message