This is the mail archive of the
mailing list for the GCC project.
Re: x86 FP optimizer behaviour
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: James Macnicol <jamesm at ee dot adfa dot edu dot au>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 22 Nov 2001 14:02:44 +0100
- Subject: Re: x86 FP optimizer behaviour
- References: <200111221058.fAMAw4018814@wattle.ee.adfa.edu.au>
James Macnicol wrote:
> 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.
P.S. Don't be mislead by the final ...1665 printed, they are really *noise* for 64 doubles
(digits10 == 15).