Date: Fri, 25 Oct 2002 19:14:08 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: rittle@latour.rsch.comm.mot.com, <current@FreeBSD.ORG> Subject: Re: Lack of real long double support Message-ID: <20021025190232.O3076-100000@gamplex.bde.org> In-Reply-To: <20021025.005338.78502540.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Oct 2002, M. Warner Losh wrote: > In message: <20021024205944.R1451-100000@gamplex.bde.org> > Bruce Evans <bde@zeta.org.au> writes: > : On Thu, 24 Oct 2002, Loren James Rittle wrote: > : > : > ... Anyways, that work exposed some issues. > : > > : > We have this in the system header: > : > > : > #define LDBL_MANT_DIG DBL_MANT_DIG > : > #define LDBL_MIN_EXP DBL_MIN_EXP > : > #define LDBL_MAX_EXP DBL_MAX_EXP > : > [...] > : > : This seems to be correct. Long double precision is not really supported > : either at complie time or runtime. The default precision (on i386's) > : is 53 bits, so (normalized) long doubles have a hard time getting any > : larger than DBL_MAX or any smaller than DBL_MIN (you can create them > : as bits or using a hardware transcendental function, but any arithmetic > : on them will convert them to double precision). > > That is incorrect. long double are supported at runtime. We use them > all the time and do get numbers outside the range of normal doubles. > There are some minor rounding issues with them, but those issues > result in a 1-2 bit rounding error in most of the cases I've looked at > in extreme detail. Such rounding errors do limit the effective range > to about 62 bits, but that's still a lot better than 53 bits you get > with doubles. Um, you get the FreeBSD default of 53 bits on i386's unless you change the FP environment using fesetprec(3) or equivalent. This thread highlighted the point that you get a larger exponent range even with 53-bit precision. > : gcc can't actually support the full range, since it doesn't control > : the runtime environement (it could issue a fninit before main() to > : change the default, but it shouldn't and doesn't). The exponent > : range is lost long before printf() is reached. E.g., > : > : long double x= DBL_MAX; > : long double y = 2 * x; > : > : gives +Inf for y since the result is doesn't fit in 53-bit precision. > : The system header correctly reports this default precision. Any header > : genrated by the gcc build should be no different, since the build should > : run in the target environment. > > that's not true. y is not +Inf, but prints as +Inf because printf and > friends do not support outside the range of a double. Oops (see another reply). > : Not really. Assembly is still required to get full control over precision. > : I'm still waiting for (C) language support to catch up. Been waiting for > : about 14 years so far. C99 clarified the semantics of floating point > : precision but is not supported by gcc (yet?). > > This is not true. No oops. gcc has no support for the C99 FENV_ACCESS stuff and still doesn't clip excess precision on assignment. These are easy to implement ... provided efficiency is not required. Bruce 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?20021025190232.O3076-100000>