Date: Thu, 24 Oct 2002 03:33:11 -0500 (CDT) From: Loren James Rittle <rittle@latour.rsch.comm.mot.com> To: current@freebsd.org Cc: rittle@latour.rsch.comm.mot.com Subject: Lack of real long double support (was Re: libstdc++ does not contain fabsl symbol) Message-ID: <200210240833.g9O8XB1W033884@latour.rsch.comm.mot.com> In-Reply-To: <20021023123653.A39814@espresso.q9media.com> References: <20021020025400.GA13776@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Note that while you're adding the C99 math stuff, you >> might want to fix up float.h, which is just wrong about long >> doubles (see PR i386/38288). > Right, I should have said no one has started committing C99 math > functions. (Reading this exchange reminded me that I promised fellow gcc developers to check on this issue with FreeBSD developers.) The gcc mainline (what will become 3.3) recently got a new implementation of ``software floating point emulation'' (contained in gcc/real.[hc] which is used to format all compile-time FP constants, etc). Along with that change, the compiler wants to provide a copy of <float.h> generated from its own knowledge of FP hardware instead of sucking information from /usr/include/float.h, as it had done in past gcc releases. I know that when we install gcc as the FreeBSD system compiler, we don't bother with such header files provided from gcc (but, for the moment please consider that people might build cross-compilers to FreeBSD and please consider that we test future releases of gcc as might be used as the FreeBSD system compiler from FSF sources). 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 [...] Yet, the FP hardware is actually configured by default to provide `long double' as: #define LDBL_MANT_DIG 53 #define LDBL_MIN_EXP (-16381) #define LDBL_MAX_EXP 16384 Indeed, FP code using long double generated by gcc 2.95.X, installed as the FreeBSD 4 system compiler, uses the full exponent range of -16381 to 16384. However, printf(), etc loses on that exponent range and reports Inf. I suspect this is why the system header misreports the FP hardware, thus the header describes the largest printable long double value, not the largest that could be held in a calculation. Anyways, two questions for FreeBSD maintainers. How should gcc, as provided from the FSF, describe the long double FP format for FreeBSD/i386 4.x? Shall we assume that no changes for FreeBSD 5.x will occur? Unless someone strongly prefers otherwise, the I lean towards wanting to describe the default FP hardware setup exactly and assume that libc changes to properly support long double stdio, etc will follow at some point. However, that also brings to mind: Are we happy with the current default FP hardware setup especially if support for long double is to be improved? At the moment we support long double in name only. There is no extra dynamic range over a double; as might be implied (and allowed by the hardware). Also, as an aside, having just learned everything there is to know about IEEE FP from a witty 80-slide presentation on the WWW by one of the original designers of the spec@Berkeley, I'd say that he would be sad that we default to use 53-bit precision mode. I'd say that it is dumb to claim we even support long double unless we change that to 64-bit precision mode... Regarding the comment in sys/i386/include/npx.h: * 64-bit precision often gives bad results with high level languages * because it makes the results of calculations depend on whether * intermediate values are stored in memory or in FPU registers. This is pure bunk when considered in broad context. Using 53-bit precision mode with high level languages while making actual calculations yields more outright undetectable precision-related errors due to algorithm design by non-numerical analysts. I know which error I'd rather *not* find in my naively-written and compiled FP code. People that write their FP code to correctly use epsilon (the one appropriate for the type of the float they are using) should never see this problem, no? I don't see why FreeBSD should cater to people that don't know how to write FP code properly (i.e. anyone that expected exact results across compilation switches, etc) at the expense of being able to write code that fully utilizes the best mode available from the CPU. People that absolutely want to avoid the problem of spilling from register to memory truncation changing with optimization level may feel free to allocate long doubles instead of doubles. Problem solved. Anyways, that is my quick speech in favor of change. I will help commit bits to the FSF gcc tree that supports whatever people want to do. It is easy to support one FP model for FreeBSD 4 and another for FreeBSD 5. Regards, Loren 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?200210240833.g9O8XB1W033884>