X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <4A9DC24F.4070309@gmail.com>
Date: Wed, 02 Sep 2009 01:54:39 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: std::arg() bug : not repetitive ?
References: <4A9DAED9 DOT 2090908 AT alice DOT it>
In-Reply-To: <4A9DAED9.2090908@alice.it>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

Angelo Graziosi wrote:
> Dave Korn wrote:
>> IIUC this is basically fixed in GCC
>> HEAD now and 4.5.0 shouldn't suffer the same problem.
> 
> Just for completeness...
> 
> With 4.5-20090827 snapshot, it does:
> 
> $ g++-4.5 arg_bug.cpp -o0 -o arg_bug
> 
> $ ./arg_bug.exe
> 0.785398
> 0.785398
> 1
> -3.06287e-17

  Thanks for checking up on this.  It's possible we might need to add some
kind of fpu mode init to the CRT.  On the other hand, comment #127 in the PR
suggests to me that maybe we need to use the new command-line flag.  Hang on a
minute... "-fexcess-precision=standard" works only for C and ObjC.

> $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave
> 
> $ ./comp_2.exe
> 0.785398
> 0.785398
> 1
> -3.06287e-17
> 
> $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave -fexcess-pr
> ecision=standard
> cc1plus: sorry, unimplemented: -fexcess-precision=standard for C++
> 
> $ 

  Bah.  Still, at least the -ffloat-store workaround still helps, for this
case at any rate.  Also, if you get GCC to use SSE instructions, there's no
issue with excess precision:

> $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave -march=pent
> ium4 -msse -mfpmath=sse
> 
> $ ./comp_2.exe
> 0.785398
> 0.785398
> 0
> 0
> 
> $

  However it does look like it's not going to get fully fixed for C++ until
someone with some serious language-lawyering skills can spend some time
defining the exact semantics.

    cheers,
      DaveK


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