X-Spam-Check-By: sourceware.org Message-ID: X-Sender: marchywka@hotmail.com In-Reply-To: From: "Mike Marchywka" To: eric.frederich@siemens.com, cygwin@cygwin.com Subject: RE: possible compiler optimization error Date: Thu, 28 Jun 2007 14:35:18 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com 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: cygwin-owner@cygwin.com On Behalf Of Brian Dessent > > Sent: Thursday, June 28, 2007 1:53 PM > > To: cygwin@cygwin.com > > 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. >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. > >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: http://cygwin.com/ml/#unsubscribe-simple >Problem reports: http://cygwin.com/problems.html >Documentation: http://cygwin.com/docs.html >FAQ: http://cygwin.com/faq/ > _________________________________________________________________ Like puzzles? Play free games & earn great prizes. Play Clink now. http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2 -- 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/