[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35488

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
FTR, this PR is linked to from here (
https://lemire.me/blog/2020/06/26/gcc-not-nearest/ ).

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

------- Comment #10 from purnnam1 at naver dot com  2008-03-07 16:15 -------
Thanks to Brian's kind comment, I have knew that the exact mechanism.
In my understannding, the conclusion is as follows;

1. GCC 3.x doesn't generate any codes for 80-bit precision. 
   the FPU h/w just uses the 80-bit internal format.

2. The double rounding (80-bit rounding in the calculation and then 64-bit
rounding in doing FST instruction) inside the FPU (not gcc generated codes)
causes this issue.

3. GCC 4.x can add an initialization code to change the default precision of
FPU.

I really appreciate that I have learned many things from this issue from many
great experts in the world.    


-- 


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[brian at dessent dot net]

------- Comment #9 from brian at dessent dot net  2008-03-07 01:20 -------
Subject:  A incorrect result in a simple division, only in 
 32-bit gcc.


> Although I knew GCC use 80-bit format internally, I thought the result should
> be same in 80-bit format.

No, it's not that gcc uses 80 bit or 64 bit "internally".  It's that the
i387 does computations for 64 bit double types in 80 bit extended mode
by default.  So it's not gcc that determines this, or that gcc changed
anything and suddenly decided "to support 64-bit internal foramt in GCC
4.x version."  gcc's double precision type has always been and always
will be 64 bits on 32 bit i386.  That has not changed in 4.x.  It's a
matter of how the i387 hardware is configured.  The -mpc64 switch
changes nothing about gcc's internal representation, it simply emits
extra code to set some fp registers to tell the hardware not to use
extended precision.  This is not a change in gcc per se.


-- 


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

------- Comment #8 from purnnam1 at naver dot com  2008-03-07 00:37 -------
Actually the 80-bit internal format will be better in converting a decimal
number into the floating point number. In this point, the 80-bit internal
format may be useful. 


-- 


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

------- Comment #7 from purnnam1 at naver dot com  2008-03-07 00:05 -------
Although I knew GCC use 80-bit format internally, I thought the result should
be same in 80-bit format.
Due to the very kind explanation about my problem, I can understand that the
result can be changed because the rounding operation occurs two times.

The cause of the problem was 'double rounding'.

Ironically, the 80-bit internal format makes MORE BIG ERROR in 64-bit floating
point calculation. 
For 64-bit output, 64-bit internal format will generate the best result becauce
IEEE-754 intendeds a result to be nearest to the true value with infinite
precision.

If GCC adopts 80-bit internal format, the final result in the 64-bit floating
point will not be the best because of the unavoidable double rounding
operation.
So, I think that it's very good decision to support 64-bit internal foramt in
GCC 4.x version. If a user uses 64-bit floating point numbers, the user will
get the more correct result by this option.

Also, I really appreciate that Andrew Pinski lets me know my alais rule
violation in C/C++. Due to Andrew's kind advice, I knew how much my violation
affects the program performance. It was not just a problem about code
portability issue. Thank you again.

I reallly appreciate you all.


-- 


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2008-03-06 23:18 -------
One more comment about this code, you are violating C/C++ aliasing rules.


-- 


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2008-03-06 23:15 -------
The division is done and then rounded to 80bits and then rounded again to
64bits.

This is not really a bug.  It is just a misunderstanding on how x87 FPU works.

        fldl    -24(%ebp)
        fldl    -32(%ebp)
        fdivrp  %st, %st(1)
        fstpl   -40(%ebp)

Either use -mfpmath=sse or don't use x86.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|DUPLICATE                   |INVALID


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2008-03-06 23:14 -------
The i?86 FPU computes values in 80bit precision by default.  Starting with
GCC 4.3 you can use -mpc64 to reduce its precision to 64bits thereby obtaining
the valid IEEE-754 result.  Or you can use -mfpmath=sse to use sse registers
for doing math (which also have a precision of 64bits).

*** This bug has been marked as a duplicate of 323 ***


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

------- Comment #3 from purnnam1 at naver dot com  2008-03-06 23:09 -------
This problem is not kind of a duplicate of #323.


-- 

purnnam1 at naver dot com changed:

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


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[purnnam1 at naver dot com]

------- Comment #2 from purnnam1 at naver dot com  2008-03-06 23:07 -------
It's not simple floating point related error!

I fully understand that the decimal number can't be converted to the exact
floating point number. so, the result may be different from our expectation.

This problem has no relation to a foolish mistake, (0.3+0.6)!=0.9.

In only ONE BASIC arithmetic operation, the output should be same between
compilers if the compilers are compliant to IEEE-754 standard and the inputs
are exactly same. If this bug is not corrected, the GCC 32-bit is NOT compliant
to IEEE-754 standard.


-- 

purnnam1 at naver dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-03-06 22:44 -------


*** This bug has been marked as a duplicate of 323 ***


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
          Component|c                           |target


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