This is the mail archive of the cygwin mailing list for the Cygwin 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: possible compiler optimization error

"Frederich, Eric P21322" wrote:

> If a program compiled with -O0 has different output than the same
> program compiled with -O1 or -O2, is that defiantly a compile error?
> I do realize that it could be a combination of compiler optimizations
> along with the platform's representation of floating point numbers, but
> isn't that something the compiler should be aware of be careful about?

On the contrary, when a program fails with optimization and not without
it is almost always a bug in the code that relies on undefined behavior
or incorrect floating point assumptions, not anything wrong with the

Try with -ffloat-store.  Or if you have a sse2 capable machine, set the
appropriate -march= and use -mfpmath=sse.  Both of these attempt to
bypass problems caused by the excess precision of 80 bit double on
i387.  If they fix the problem, it's a bug in your code, not anything to
do with the compiler.  It looks like you limit the precision in the
output in your printfs to 15 places, but then you don't understand why
comparison operators don't compare the same... that is very telling, in
that you don't understand the excess precision problem.  Of course they
look the same if you limit the precision!  But that's not how the
comparison operators work, as they operate on the raw 80 bit values.

If you want a definitive answer then you need to provide a standalone
testcase that compiles.  Sample code taken out of context that can't be
compiled is significantly less useful.


Unsubscribe info:
Problem reports:

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