Received: by 10.180.98.234 with SMTP id el10mr73266wib.3.1348190454193;
        Thu, 20 Sep 2012 18:20:54 -0700 (PDT)
Path: q11ni3539513wiw.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!94.232.116.13.MISMATCH!feed.xsnews.nl!border-3.ams.xsnews.nl!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!newsfeed.straub-nv.de!news-1.dfn.de!news.dfn.de!news.informatik.hu-berlin.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: Tobias Burnus <bur...@net-b.de>
Newsgroups: comp.lang.fortran
Subject: Re: Intrinsic function for dp vs sp?
Date: Mon, 17 Sep 2012 10:55:18 +0200
Organization: Freie Universitaet Berlin
Lines: 43
Message-ID: <5056E576.1060506@net-b.de>
References: <a5360efa-9d5e-4e70-bbb7-b0c956a143c4@f6g2000yqi.googlegroups.com> <k2mflt$17e$1@dont-email.me> <8ef13f88-58c7-47e6-84fc-a5e94db6205f@b8g2000yqh.googlegroups.com> <k2nmda$q47$1@speranza.aioe.org> <1kq927s.5sh2zyx1fkk8N%nospam@see.signature> <k2nval$unq$1@dont-email.me> <1kq99zu.tcwbv41sntun8N%nospam@see.signature> <7a400b86-a5fc-44ef-9661-b8e2daa7c5a2@r7g2000yqa.googlegroups.com> <ec9ff9d8-450a-4e6a-b2ed-ab48c3fbb25c@googlegroups.com>
Mime-Version: 1.0
X-Trace: news.uni-berlin.de R5jPDljTQyCMx7iXYd9RvgradR6wE4cT44khBnyv9sYN51hOEN2/34u0Dsl1cG
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0
In-Reply-To: <ec9ff9d8-450a-4e6a-b2ed-ab48c3fbb25c@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 09/17/2012 10:27 AM, robert.corb...@oracle.com wrote:
>> I have two pieces of code, one in C and the translated version in
>> >
>> >Fortran (see below). I'm translating some vibration code and am
>> >
>> >observing small differences at a few point points.  Most of the time
>> >
>> >the numbers are in complete lockstep - down to the least significant
>> >
>> >digit.  But in this case I see both routines called with the exact
>> >
>> >same arguments BUT the iC vectors (return values) differ:
>> >
>> >

> My guess is that x87 instructions are involved.  I suspect that gfortran
> is using the x87 instructions and gcc is not.  Another possibility is
> that both compilers are using the x87 instructions, but that gcc is
> chopping back the precision of the function results and gcc does not.


In principle, GCC treats Fortran and C in the same way.* However, since 
GCC 4.5, GCC's C compiler supports -fexcess-precision=standard which is 
enabled with e.g. -std=c99. See:

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fexcess_002dprecision-886

Try -mfpmath=sse or -ffloat-store. (The former option requires that 
-march= explicitly or implicitly specifies a CPU which supports SSE.) 
SSE doesn't have the excess precision and float-store moves the variable 
out of the register and back to get rid of the excess precision. (On a 
64bit x86-64 CPU, SSE is used by default.)

Of course, one can also explcitly use the excess precision via 
gfortran's REAL(10) which matches GCC's long double (on x86/x86-64 
hardware). Or [with GCC 4.6 and later] you could use REAL(16)/__float128 
(on C together with libquadmath's sinq etc.) to have even more precision 
and lower performance ;-)

Tobias

* There are some exceptions like how parentheses are handled for 
optimizations or for the handling of complex variables.