Re: optimization/7719: gcc with -O2 generates wrong code

[Eric Botcazou <ebotcazou@libertysurf.fr>]

The following reply was made to PR optimization/7719; it has been noted by GNATS.

From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Petr.Savicky@ff.cuni.cz
Cc: gcc-bugs@gcc.gnu.org,
 nobody@gcc.gnu.org,
 gcc-gnats@gcc.gnu.org
Subject: Re: optimization/7719: gcc with -O2 generates wrong code
Date: Wed, 19 Feb 2003 15:53:38 +0100

 > Yes, using -O2 together with -ffloat-store eliminates the problem.
 > Moreover, the fact that a double value may change just by storing
 > and reloading from memory explains the behaviour of the program.
 
 Thanks for the quick feedback.
 
 > OK, this is not a bug of the compiler itself, but it is a bug in
 > the default settings of gcc on x86. Everybody knows that the results
 > of computer arithmetic are not safe, may have different results on
 > different processors and definitely do not satisfy things like
 > (a+b)+c = a+(b+c). Here, however, the problem is not in the operations
 > with the numbers, but with keeping their values untouched. The value of a
 > variable changes during a sequence of operations which do not involve it.
 > The change may influence not only equality tests, but also inequality
 > tests, which cannot be avoided. This is hard to accept as a correct
 > behaviour even on a processor with a conceptually buggy design.
 
 You might want to try '-march=pentium[34] -mfpmath=sse' then, if you have of 
 course the right hardware.
 
 > The current success of GNU Project heavily relies on using its
 > software on x86. Perhaps, this may be a reason to be more friendly
 > to this processor and put -ffloat-store into the definition of -O2,
 > which is frequently used as a default.
 
 As someone else said, '-ffloat-store' is a big hammer which seriously harms
 the runtime performance of programs.
 
 -- 
 Eric Botcazou