optimization/7719: gcc with -O2 generates wrong code

[Eric Botcazou]

> 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