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'
*** This bug has been marked as a duplicate of 323 ***
Note every GCC from 2.95.3 gives the same result.
x and a should be identical, so assertion should not fail at all. since a is assigned to x, it has *SAME* rounding precision.
This is a target problem, as the RTL is correct. Looks like there is a forgotten rounding back to float.
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?
(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 ***
It should be logical equivalent regardless of how it stored in memory.
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 ***
Surely assigning a float value to another float variable should not cause any rounding as they are same data type.
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 ***
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.
(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.
(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?
(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 ***
> > 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.
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.
(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 ***
> Again just use -ffloat-store as required not get the excessive precision. > This should included in gcc spec file by defaults.
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 ***
(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!).
(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 ***
> 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.
This is a target problem, as the RTL is correct. Looks like there is a forgotten rounding back https://tinyurl.com/y46wuubk to float. 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); } Fixed???