Subject: Re: -fno-builtin world breaks in gperf - msg#00052

Previous Message by Date: click to view message preview

Re: -fno-builtin world breaks in gperf

Thus spake Mike Barcroft <mike@xxxxxxxxxxx>: > Mike Barcroft <mike@xxxxxxxxxxx> writes: > > Dag-Erling Smorgrav <des@xxxxxxxx> writes: > > > Kris Kennaway <kris@xxxxxxxxxxxxxx> 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. > > > > 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: > > [...] > > > > You might want to take a look at the fpclassify() implementation. It > > doesn't look like your findings are correct. Specifically, see the > > bitfield layouts in _fpmath.h. > > > > IIRC, long doubles are as follows: > [...] > > - ia64 IEEE quad (128-bit) format > > Oops, this is actually just a double-extended 80-bit, but aligned to > 16-bytes. I'm in the progress of testing a fix for _fpmath.h. BTW, float.h for ia64 is wrong about long doubles, too. In fact, I'll bet *most* archtectures have it wrong, since they all copied from i386, and even i386 had it wrong until a few months ago. Here's the (unverified) output of 'enquire -f' on an ia64 Linux box. DECIMAL_DIG will probably need to be updated according to the formula in the standard as well. /* Number of base-FLT_RADIX digits in the significand of a long double */ #undef LDBL_MANT_DIG #define LDBL_MANT_DIG 64 /* Number of decimal digits of precision in a long double */ #undef LDBL_DIG #define LDBL_DIG 18 /* Difference between 1.0 and the minimum long double greater than 1.0 */ #undef LDBL_EPSILON #define LDBL_EPSILON 1.08420217248550443401e-19L /* Minimum int x such that FLT_RADIX**(x-1) is a normalised long double */ #undef LDBL_MIN_EXP #define LDBL_MIN_EXP (-16381) /* Minimum normalised long double */ #undef LDBL_MIN #define LDBL_MIN 3.36210314311209350626e-4932L /* Minimum int x such that 10**x is a normalised long double */ #undef LDBL_MIN_10_EXP #define LDBL_MIN_10_EXP (-4931) /* Maximum int x such that FLT_RADIX**(x-1) is a representable long double */ #undef LDBL_MAX_EXP #define LDBL_MAX_EXP 16384 /* Maximum long double */ #undef LDBL_MAX #define LDBL_MAX 1.18973149535723176502e+4932L /* Maximum int x such that 10**x is a representable long double */ #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 4932 To Unsubscribe: send mail to majordomo@xxxxxxxxxxx with "unsubscribe freebsd-standards" in the body of the message

Next Message by Date: click to view message preview

Re: -fno-builtin world breaks in gperf

On Tue, 18 Feb 2003, Dag-Erling Smorgrav wrote: > Bruce Evans <bde@xxxxxxxxxxx> writes: > > libstdc++ is broken too, starting with normally using a pre-configured > > (committed) config.h which is wrong if you add -fno-builtin to CFLAGS. > > No, it looks to me like config.h is correct but the code is wrong in > that it doesn't respect it (i.e. it uses fabsl() even if config.h > "knows" the system doesn't have fabsl()) Right. I forgot that -fno-builin only turns off the mapping of standard functions to builtins :-(. 95% of the references to *BUILTIN* in libstdc++ seem to be in to autconfig or (Change)Log unused macros. Bruce To Unsubscribe: send mail to majordomo@xxxxxxxxxxx with "unsubscribe freebsd-standards" in the body of the message

Previous Message by Thread: click to view message preview

Re: -fno-builtin world breaks in gperf

On Tue, 18 Feb 2003, Dag-Erling Smorgrav wrote: > Kris Kennaway <kris@xxxxxxxxxxxxxx> 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@xxxxxxxxxxx with "unsubscribe freebsd-standards" in the body of the message

Next Message by Thread: click to view message preview

Re: -fno-builtin world breaks in gperf

On Tue, 18 Feb 2003, Dag-Erling Smorgrav wrote: > Bruce Evans <bde@xxxxxxxxxxx> writes: > > libstdc++ is broken too, starting with normally using a pre-configured > > (committed) config.h which is wrong if you add -fno-builtin to CFLAGS. > > No, it looks to me like config.h is correct but the code is wrong in > that it doesn't respect it (i.e. it uses fabsl() even if config.h > "knows" the system doesn't have fabsl()) Right. I forgot that -fno-builin only turns off the mapping of standard functions to builtins :-(. 95% of the references to *BUILTIN* in libstdc++ seem to be in to autconfig or (Change)Log unused macros. Bruce To Unsubscribe: send mail to majordomo@xxxxxxxxxxx with "unsubscribe freebsd-standards" in the body of the message