X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
Subject:	RE: possible compiler optimization error
Date:	Thu, 28 Jun 2007 14:28:16 -0400
Message-ID:	<C6EEDB0EB45A56439F73B1D23E39694A35C819@USORL02P702.ww007.siemens.net>
In-Reply-To:	<4683F56D.53B8E259@dessent.net>
References:	<C6EEDB0EB45A56439F73B1D23E39694A35C7EC AT USORL02P702 DOT ww007 DOT siemens DOT net> <4683F56D DOT 53B8E259 AT dessent DOT net>
From:	"Frederich, Eric P21322" <eric DOT frederich AT siemens DOT com>
To:	<cygwin AT cygwin DOT com>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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/

- Raw text -