From owner-freebsd-current Mon Oct 28 20:42:10 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 1BF5F37B401 for ; Mon, 28 Oct 2002 20:42:07 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91CE443E4A for ; Mon, 28 Oct 2002 20:42:05 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9T4fvpk033586; Mon, 28 Oct 2002 21:41:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 28 Oct 2002 21:40:57 -0700 (MST) Message-Id: <20021028.214057.108404482.imp@bsdimp.com> To: rittle@labs.mot.com, rittle@latour.rsch.comm.mot.com Cc: current@freebsd.org, bde@zeta.org.au, dschultz@uclink.Berkeley.EDU Subject: Re: Lack of real long double support From: "M. Warner Losh" In-Reply-To: <200210290211.g9T2BBcP010112@latour.rsch.comm.mot.com> References: <20021025182223.D3076-100000@gamplex.bde.org> <200210290211.g9T2BBcP010112@latour.rsch.comm.mot.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 message: <200210290211.g9T2BBcP010112@latour.rsch.comm.mot.com> Loren James Rittle writes: : #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 (); : } #include #include #include long double oneld() { return 1.0L; } print(char *msg, long double ld) { uint8_t *c; int i; c = (uint8_t *) &ld; printf("%s = ", msg); for (i = 0; i < sizeof(ld); i++) printf("%02x ", *c++ & 0xff); printf("\n"); } main () { long double a; long double b; fpsetprec(FP_PE); a = oneld(); b = oneld() + LDBL_EPSILON; print("a ", a); a += LDBL_EPSILON; print("a++", a); print("b ", b); } This works. I'm not sure why this isn't the default. It looks like we have hacks in the local tree to do this, which is why I thought that it worked great by default.... : 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). Yup. : > 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). This is true too. See the fpsetprec() call that I had to add to make things work above. : 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. Yes. The standard didn't anticipate the fp hardware that intel made. : 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? One could do something like: #define LDBL_EPSILON (fpgetprec() == FP_PE ? _LDBL_EPSILON : DBL_EPSILON) But as you said, this isn't a compile time constant. I'm not sure that it would matter in any real context. I don't think that you can do floating point in the preprocessor... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message