X-Spam-Check-By: sourceware.org Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: possible compiler optimization error Date: Thu, 28 Jun 2007 14:28:16 -0400 Message-ID: In-Reply-To: <4683F56D.53B8E259@dessent.net> References: <4683F56D DOT 53B8E259 AT dessent DOT net> From: "Frederich, Eric P21322" To: X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id l5SISffP026025 > From: cygwin-owner AT cygwin DOT com On Behalf Of Brian Dessent > Sent: Thursday, June 28, 2007 1:53 PM > To: cygwin AT cygwin DOT 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/