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

Send some disassembled code fragments- it should be pretty clear.
Or, you can probably cast  and dump as hex/bin and see what is going on.

From: "Frederich, Eric P21322" <>
To: <>
Subject: RE: possible compiler optimization error
Date: Thu, 28 Jun 2007 14:28:16 -0400

> From: On Behalf Of Brian Dessent
> Sent: Thursday, June 28, 2007 1:53 PM
> To:
> Subject: Re: possible compiler optimization error

Thanks for looking at it. I am in unfamiliar water here.

> 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.

-mfpmath=sse didn't work but -msse did. Here are some new findings...

-ffloat-store     -O2  passes
-march=i686       -O2  fails
-march=i686 -sse  -O2  fails
-march=i686 -sse2 -O2  passes

> 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.
> 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.

I do realize that they may in fact differ way out there beyond 15
decimal places.
What I don't understand is how two numbers pass a ==, then fail a >=,
then pass a >= unless (after compiler optimizations) the second and
third comparisons are actually comparing copies of these numbers which
aren't "bit-exact" copies.
Is this what you're saying might be happening and what -ffloat-store is
supposed to resolve?
If so, that makes sense and I can accept that.

> 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.

I really want to but it is a huge program and I am afraid that if I
create a chopped down example I can't guarantee that the same
optimizations will happen.

Unsubscribe info:
Problem reports:

Like puzzles? Play free games & earn great prizes. Play Clink now.

-- Unsubscribe info: Problem reports: Documentation: FAQ:

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