[Bug c++/12043] New: long double calcluation seems broken

[Bug c++/12043] New: long double calcluation seems broken

[jlquinn at optonline dot net]

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

           Summary: long double calcluation seems broken
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jlquinn at optonline dot net
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu

While working on improved printf for libstdc++, I came across what appears to be
a problem with long double math.  In the attached code, I THINK that x.d is a
valid long double (96 bits of which 80 are actually used).  The test case cam
because I was trying to generate random long doubles to compare results and
getting problems.

The problem can be seen in the value of q1.

[Bug c++/12043] long double calcluation seems broken

[jlquinn at optonline dot net]

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 jlquinn at optonline dot net  2003-08-24 01:27 -------
Created an attachment (id=4646)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4646&action=view)
Testcase for broken long double

Compile like: g++ -g ldtest.cc

[Bug target/12043] long double calcluation seems broken

[pinskia at gcc dot gnu dot org]

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target
           Keywords|                            |wrong-code

[Bug target/12043] long double calcluation seems broken

[pinskia at gcc dot gnu dot org]

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   GCC host triplet|i686-pc-linux-gnu           |
 GCC target triplet|                            |i686-pc-linux-gnu


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-24 02:21 -------
The RTL looks good to me but I cannot read 387 assembly.  I just think printf is printing 
out the floating point wrong, making this a glibc bug.

[Bug target/12043] long double calcluation seems broken

[pinskia at gcc dot gnu dot org]

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-24 02:28 -------
On i686-unknown-openbsd3.1, this testcase prints:
Inf
NaN
(other output removed)

See how these two are different (Yes I know it is really printing out the double versions 
but still it says the hex number you enter is not a number and not 0 or Int) and not the 
same so this is definitely a glibc bug.

[Bug target/12043] long double calcluation seems broken

[pinskia at gcc dot gnu dot org]

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-24 15:47 -------
I am going to reopen this based on what I got in my person email because I thought in long double 
(XF which is 96 bits with 16 bits unused (not TF, which is 128bit))
I'm sending this directly to you since I don't want to reopen the bug
bug if I'm wrong, but...

I thought the hex looks like a valid long double.  If I understand
ieee fp correctly (and I probably don't), the first word containing 0
has 16 bits of unused, 1 sign bit, and 15 exponent bits.  I think that
the exponent bits must be 0x7fff to be INF or NAN.  If so, then this
is actually a valid number.

Thanks,
Jerry

[Bug target/12043] long double calcluation seems broken

[jlquinn at gcc dot gnu dot org]

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 jlquinn at gcc dot gnu dot org  2003-09-24 05:05 -------
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.

[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.

[Bug target/12043] long double calcluation seems broken

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-24 22:14 -------
This is not a GCC bug, there is no way as GCC emits the right asm.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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