Date: Tue, 18 Feb 2003 12:05:03 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Kris Kennaway <kris@obsecurity.org>, <standards@FreeBSD.ORG> Subject: Re: -fno-builtin world breaks in gperf Message-ID: <20030218111318.I7804-100000@gamplex.bde.org> In-Reply-To: <xzp8ywezc7z.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Feb 2003, Dag-Erling Smorgrav wrote: > Kris Kennaway <kris@obsecurity.org> writes: > > On Mon, Feb 17, 2003 at 03:46:15PM +0100, Dag-Erling Smorgrav wrote: > > > Our libm doesn't seem to support long double at all, yet our libstdc++ > > > requires long double support. libstdc++ is broken too, starting with normally using a pre-configured (committed) config.h which is wrong if you add -fno-builtin to CFLAGS. > > I pointed this out a while ago..looks like no-one did anything about > > it yet. > > I've looked at it, and it looks Hard[tm]. The four architectures I > tested (alpha, ia32, ia64, sparc64) had four different representations > for long double: It's not hard for fabsl(). Just modify the recently committed signbit() to clear the sign bit instead of returning it, not quite like s_fabs.c and s_fabsf.c already clear the sign bit for fabs() and fabsf(). It's hard, or at least large, for all the 'l' functions. > So far, I've concluded the following: > > - alpha doesn't have a separate long double type - it's just an alias > for double which has an 11-bit exponent and a 52-bit mantissa. > > - ia32 and ia64 seem to have 80-bit long doubles which they store in > 96 and 128 bits, respectively. They seem to use a 16-bit exponent > and a 63-bit mantissa. > > - sparc64 seems to have 80-bit long doubles which it stores in 128 > bits (it's big-endian, so what looks like trailing padding is > actually leading padding like on ia32 and sparc64). It seems to > use a 15-bit exponent and a 64-bit mantissa. > > I haven't had a chance to look at powerpc yet. These numbers can now be read off from the struct definitions in libc/*/_fpmath.h. They are almost correct. The i386 exponent/mantissa are 15/64, not 16/63. Similarly for the ia64 except the mantissa size. ia64, powerpc and sparc64 all have a 128-bit format with a 96-bit mantissa. I'm not sure if all 96 bits are used. > An implementation of the ISO C long double math functions (all 92 of > them, not counting long double complex!) would have to handle all the > above cases, either in separate files or in #ifdef hell. For alpha, See glibc. It seems to have both, plus extra complications and combinatorial explosion from doing things in asm too %-). > we could just define macros which cast the arguments to double, call > the appropriate double function and cast the result to long double, > but for the three other platforms (+ ppc?) we need actual code. We (er, you) could cast for all machines, but this would give a low quality implementation and might confuse autoconfig'ed ports into not using better workarounds for missing 'l' functions. OTOH, implementing most of the 'f' functions by casting to double would increase the quality of most of them. Some of the 'f' functions are slower than the double functions since they don't use the hardware functions, and some of them (powf() and __ieee754_rem_pio2f() at least) are buggy due to mistranslation of magic numbers. 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?20030218111318.I7804-100000>