RE: possible compiler optimization error

["Mike Marchywka" <marchywka at hotmail dot com>]

I sent a private reply to the user but, without looking at the code, some 
compiler
options give up consistency for sake of speed. And, if you are really using
floating point as intended, and not doing something like making arthmetic
encoders, you should NEVER need to do a floating point equality compare.

It is entirely possible that two sequential "==" tests are comparing 
differently
rounded numbers- in one case it could be something left in a register and in
another compare it is looking at something that changed precision during a
store/load.

You would really need to look at the generated code to get some idea
what is going on but I would suspect precisions issues as much as
corruption/NaN etc.


> From: "Dave Korn" <dave.korn@artimi.com>
> To: <cygwin@cygwin.com>
> Subject: RE: possible compiler optimization error
> Date: Thu, 28 Jun 2007 18:39:19 +0100
>
> On 28 June 2007 18:19, Frederich, Eric P21322 wrote:
>
> > On Windows I have found that a program I wrote fails when compiled with
> > -O1 and -O2 but runs fine with -O0.
> > The program behaves correctly on Linux and Solaris with or without
> > optimizations.
>
>   Your code has a bug, most likely an uninitialised or otherwise stray
> pointer, but could be anything that causes undefined behaviour.  It works 
> on
> Linux/Solaris by good fortune, because whatever memory addresses you're
> stomping all over just happen to be free and safe to stomp on on those
> platforms, whereas windows systems have different process space layout
>
> > If a program compiled with -O0 has different output than the same
> > program compiled with -O1 or -O2, is that defiantly a compile error?
>
>   No.  Very occasionally it is a genuine compiler bug in one of the
> optimisation passes, but the *vast* majority of such 'bugs' are actually in
> the source code fed to the compiler.  (Like many utilities, the compiler
> cannot always detect when it is fed invalid input, and may sometimes 
> silently
> produce invalid output as a result.)
>
>   Now, there /could/ be a compiler bug, but unless you can present us with 
> a
> testcase that we can compile ourselves and test out, it's not going to be 
> easy
> to help you.  Fragmentary code snippets aren't useful.  For advice on how 
> to
> write a really good compiler bug report, see the guidelines at
> http://gcc.gnu.org/bugs.html
>
>
>     cheers,
>       DaveK
> --
> Can't think of a witty .sigline today....
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

_________________________________________________________________
Who's that on the Red Carpet? Play & win glamorous prizes. 
http://club.live.com/red_carpet_reveal.aspx?icid=REDCARPET_hotmailtextlink3


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/