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

[Petr.Savicky@ff.cuni.cz]

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

From: Petr.Savicky@ff.cuni.cz
To: ebotcazou@gcc.gnu.org, Petr.Savicky@cuni.cz, gcc-bugs@gcc.gnu.org,
  gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: optimization/7719: gcc with -O2 generates wrong code
Date: Wed, 19 Feb 2003 15:28:47 +0100

 On Wed, Feb 19, 2003 at 08:35:13AM -0000, ebotcazou@gcc.gnu.org wrote:
 > Synopsis: gcc with -O2 generates wrong code
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: ebotcazou
 > State-Changed-When: Wed Feb 19 08:35:13 2003
 > State-Changed-Why:
 >     Probably not a bug. On x86, at -O2, floating point values
 >     may be kept in FP registers when doing comparison with
 >     others stored in memory. Now x86 FP registers have
 >     extra-precision over a 'double', which may invalid
 >     an equality comparison. Compile your code with '-ffloat-store'
 >     if it relies on exact IEEE floating-point semantics.
 
 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.
 
 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.
 
 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.
 
 For me as a Linux user, it was not nice to have the bug only under Linux
 and not under Windows, just because the Windows version was compiled
 by a different compiler.
 
 Best wishes
 
   Petr Savicky