Ian Lance Taylor ian@airs.com
Sat Apr 2 16:45:00 GMT 2005

Manan Chopra <mchopra@wisc.edu> writes:

>    I am a Physics student.  We in our research group have been
> developing a molecular simulation software.
> So to make our code run fast we are using gcc optimizations but i have
> got a case in which gcc shows different behaviour when run with or
> without optimization.
> And i am not very sure how to correct this situation.
> Below is the part of code in which i am seeing this behaviour. THIS IS
> BUGGY LINE is the exact line which gives different results with and
> without optimization.
> The value of  x[i] at that point is 1.5(exact) value of box_xh is  2.1
> and rnx is 0.6 so icelx should evaluate to 6. which it does if i dont
> use optimization but when i switch optimization it gives icelx =
> 5. which is not correct. One moe thing i should mention real is double
> in my code.

You neglected to mention what type of machine you are running on.  I
would guess that you are using some sort of x86 architecture.  On the
x86 the type double is 64 bits, but floating point computation is done
by default in 80 bit registers.  The difference in precision can cause
unexpected effects.

In particular neither 0.6 nor 2.1 can be precisely represented in a
binary floating point format.  When compiling without optimization,
the values are forced back to 64-bits on the stack at each step.  When
compiling with optimization this does not happen.  With optimization
the computation using values in 80-bit precision yields a value just
smaller than 6.  When you then call floor, this is reduced to 5.

The quick workaround is to use the -ffloat-store option, which will
probably fix your immediate problem.  Or if you have a sufficiently
new processor and compiler you could try -mfpmath=sse.  Medium term
you should avoid discontinuous functions like floor and you should
avoid comparing floating point values for equality--instead check
whether they differ by some appropriately small epsilon.  Longer term
I would recommend a better understanding of computer approximations of
floating point arithmetic.


More information about the Gcc-help mailing list