Bug 21809 - Floating Optimization Bug
Summary: Floating Optimization Bug
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-29 16:21 UTC by Haren Visavadia
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host:
Target: i686-pc-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Haren Visavadia 2005-05-29 16:21:27 UTC
This problems occurs with GCC 3.4.4, gcc-4.0-20050521 snapshot and
gcc-4.1-20050528 snapshot.


test-case.c:
#include <assert,h>
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}


This case (test-case.c) works with gcc -O0 without a problem.

But with gcc {-O1,-O2,-O3,-Os} causes the following error:
test: test.c:9: main: Assertion 'a == x' failed'
Comment 1 Andrew Pinski 2005-05-29 16:24:42 UTC

*** This bug has been marked as a duplicate of 323 ***
Comment 2 Andrew Pinski 2005-05-29 16:39:34 UTC
Note every GCC from 2.95.3 gives the same result.
Comment 3 Haren Visavadia 2005-05-29 16:44:12 UTC
x and a should be identical, so assertion should not fail at all.

since a is assigned to x, it has *SAME* rounding precision.
Comment 4 Andrew Pinski 2005-05-29 17:04:54 UTC
This is a target problem, as the RTL is correct.
Looks like there is a forgotten rounding back to float.
Comment 5 Haren Visavadia 2005-05-29 17:58:10 UTC
This also occurs with double, using test-case.c but with float replaced with
double, so code fragment looks like:

test-case.c:
#include <assert,h>
volatile double x = 3;
int main()
{
double a = 1 / x;
x = a;
assert(a == x);
}


Should I put this as separate PR?
Comment 6 Andrew Pinski 2005-05-29 18:27:35 UTC
(In reply to comment #5)
> Should I put this as separate PR?

Actually this is all a dup of bug 323.  The "problem" is excessive pression, which most non fp 
developers will not know about, read the full PR 323 and the references to papers which talk about this.

*** This bug has been marked as a duplicate of 323 ***
Comment 7 Haren Visavadia 2005-05-29 19:01:48 UTC
It should be logical equivalent regardless of how it stored in memory.
Comment 8 Andrew Pinski 2005-05-29 19:06:28 UTC
when you store it to memory the precission goes down (aka rounding) read 323 and all the rest of the 
problems related to it.

*** This bug has been marked as a duplicate of 323 ***
Comment 9 Haren Visavadia 2005-05-29 19:18:51 UTC
Surely assigning a float value to another float variable should not cause any
rounding as they are same data type.
Comment 10 Andrew Pinski 2005-05-29 19:24:42 UTC
Please go read the papers.  Basically x87 is broken in this respect, use either a different machine or use 
SSE.

*** This bug has been marked as a duplicate of 323 ***
Comment 11 Haren Visavadia 2005-05-29 19:28:37 UTC
Read the code carefully:

test-case.c:
#include <assert,h>
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}


Notice x = a before assertion, both of these variables are of the same data type.

This is *not* related to precission.

This is behaviour, you would expect from a compiler.
Comment 12 Andrew Pinski 2005-05-29 19:31:35 UTC
(In reply to comment #11)
> This is *not* related to precission.
> 
> This is behaviour, you would expect from a compiler.

For non floating point, yes but floating point is different with respect with precission.
Comment 13 Haren Visavadia 2005-05-29 19:32:08 UTC
(In reply to comment #10)
> Please go read the papers.  Basically x87 is broken in this respect, use
eithera different machine or use 
> SSE.
It be good idea to do that by default then?
Comment 14 Andrew Pinski 2005-05-29 19:35:00 UTC
(In reply to comment #13)
> (In reply to comment #10)
> > Please go read the papers.  Basically x87 is broken in this respect, use
> eithera different machine or use 
> > SSE.
> It be good idea to do that by default then?
It is on x86_64, remember SSE is not every where.

Just use -ffloat-store instead.

*** This bug has been marked as a duplicate of 323 ***
Comment 15 Haren Visavadia 2005-05-29 19:36:52 UTC
> > It be good idea to do that by default then?
> It is on x86_64, remember SSE is not every where.
> 
x86-64 has support for SSE3 so it would use that instead.


Comment 16 joseph@codesourcery.com 2005-05-29 19:37:09 UTC
Subject: Re:  New: [3.4/4.0/4.1 Regression]
 Floating Optimization Bug

On Sun, 29 May 2005, themis_hv at yahoo dot co dot uk wrote:

> This case (test-case.c) works with gcc -O0 without a problem.
> 
> But with gcc {-O1,-O2,-O3,-Os} causes the following error:
> test: test.c:9: main: Assertion 'a == x' failed'

Not if you use -ffloat-store, as is required if you wish to avoid such 
instances of paradoxical excess precision.

Comment 17 Andrew Pinski 2005-05-29 19:43:55 UTC
(In reply to comment #15)
> x86-64 has support for SSE3 so it would use that instead.

Actually that is wrong, the subset which is supported by AMD and Intel (EM64T) only have SSE, SSE2, 
and MMX.   AMD's x86_64 which in my mind the true x86_64 has also support for 3dnow.  Intel's EM64t 
have SSE3.

Again just use -ffloat-store as required not get the excessive precision.

*** This bug has been marked as a duplicate of 323 ***
Comment 18 Haren Visavadia 2005-05-29 19:46:40 UTC
> Again just use -ffloat-store as required not get the excessive precision.
> 

This should included in gcc spec file by defaults.


Comment 19 Andrew Pinski 2005-05-29 19:47:55 UTC
That is not going to change, the assert is allowed to fail by the standard by the way.

*** This bug has been marked as a duplicate of 323 ***
Comment 20 Haren Visavadia 2005-05-29 19:51:15 UTC
(In reply to comment #19)
> That is not going to change, the assert is allowed to fail by the standard by
the way.
> 

Yes, assert fails in some cases (I think of a hundred at moment!).

Comment 21 Andrew Pinski 2005-05-29 19:56:03 UTC
(In reply to comment #20)
> Yes, assert fails in some cases (I think of a hundred at moment!).

See now you did not read my comment, I said it is _____ALLOWED____ by the standard to ___FAIL___.
How much clearer do you need it?

ALSO READ UP on excessive precision.  You seem like someone who does not want to do the leg work 
of getting your programs fixed so you don't depend on this.

Note this is how x87 works, live with it.  Just stop buying x86 machines if you don't like this.

*** This bug has been marked as a duplicate of 323 ***
Comment 22 Haren Visavadia 2005-05-29 20:09:27 UTC
> You seem like someone who does not want to do the leg work 
> of getting your programs fixed so you don't depend on this.
Regardless, other poeple dependant on it.