This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86 FP optimizer behaviour


James Macnicol wrote:

> Hello,
>
>         I have spent today beating my head against a brick wall with
> the following code (made somewhat more concise than what I started
> with).  On the surface it looks like an optimizer bug: the value
> printed out is different (and wrong) if you compile with -O than
> without.  Notice in the second case however, that the problem goes
> away if you move the printf statement to be before the comparison that
> fails.  So I'm not sure what the actual problem is given the presence
> of the printf shouldn't affect anything at all (surely the optimizer
> can't do anything with it) ....

roughly, IMHO the problem with your testcase is that you are battling with undefined
behaviour (an hard comparison versus 0.008 in the if comparison... brrr...). In those
cases, it is well known that *any* difference in the code (your second testcase) or in the
optimization switches (-O0 vs -O1) may lead to different results at run time.

Indeed, I have tried your testcase with other compilers and one among them leads to an
executable which outputs *always* 1 both for -O0 and -O1, that is something still
different from your cases.

Really, with undefined behaviour, anything may happen...

Anyway, other people, more in the known as far as floating point computations are
concerned (e.g., Alexandre Oliva?) may comment on this.

Cheers,
Paolo.

P.S. Don't be mislead by the final ...1665 printed, they are really *noise* for 64 doubles
(digits10 == 15).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]