[Bug target/12043] long double calcluation seems broken

[wilson at specifixinc dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12043



------- Additional Comments From wilson at specifixinc dot com  2003-09-25 05:37 -------
Subject: Re:  long double calcluation seems broken

jlquinn at gcc dot gnu dot org wrote:
> I did some more digging into floating point formats.  For 80 bit extended, the
> top bit of the mantissa is supposed to be set for normalized numbers.  My test case
> disobeys that rule.  So, my earlier claim that long double math is broken is
> apparently false.
> 
> What I can't figure out is, what is this bit pattern according ieee?  80 bit
> extended has a number of disallowed patterns.

A normalized number means that the fraction is between 1 and 2, which 
means that the fraction always starts with a one bit.  In 32-bit and 
64-bit IEEE formats, this one bit is not part of the format, rather it 
is implied.  This is refered to as the hidden bit.  Notice that there is 
only 23 bits for holding the fraction in single, but the format holds 24 
bits of precision in the fraction, because of the hidden bit.

IEEE requires only 79 bits for the double extended format.  Since this 
is a very inconvenient number, most implementations get rid of the 
hidden bit, to make this a round 80 bits.  This means that the first 
fraction bit must always be a one for a normalized number.  If the first 
fraction bit is not a one, then you do not have a valid number, and the 
FP hardware may trap, or give meaningless results, or do anything else.