This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Testing __float128 [Cygwin]
- From: Tobias Burnus <burnus at net-b dot de>
- To: FX <fxcoudert at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, angelo dot graziosi at alice dot it, Jerry DeLisle <jvdelisle at verizon dot net>
- Date: Wed, 08 Sep 2010 08:21:57 +0200
- Subject: Re: Testing __float128 [Cygwin]
- References: <5943C13C-82B9-4594-A43C-E02DD07BDB18@gmail.com>
On 09/08/2010 07:41 AM, FX wrote:
Regarding this Cygwin thread, am I correct in summarizing that the only problem revealed so far is libquad using sqrtl()/cbrtl()? If so, I will teach the next version of libquad to use the double versions of these functions (sqrtl/cbrt) instead
Can't you add a configure check and use sqrt/cbrt only if the long
double variants are not available?
On 09/07/2010 06:58 PM, Angelo Graziosi wrote:
At this point, I have just a rhetorical question: why then the Cygwin
version of G95 supports QP?
If one looks at Andy's implementation of sqrt, one sees that he only
does basic arithmetic without using any library call - thus, cbrtl and
sqrtl are never used and thus you do not have those link problems.
In summary: Andy started earlier,* he has taken a different route (not
using __float128** and also implementing the basic support in the
library), and his implementation seems to be incomplete. For instance,
if I try under x86-64-linux the program
real(16) :: r
r = 2.0_16
print *, sqrt(r)
print *, r**3.4
end
the sqrt works - but I get linkage errors for r**3.4 (undefined
reference to "_g95_power_r16"). For sqrt the result matches the one of
ifort - and for compile-time evaluation, 2.0_16**3.4 also worked.
I do not know how this compares with gfortran's libquad, but I had the
impression that it supports all intrinsics. (So far, I have not yet
tried gfortran's quad support.)
Tobias
* Kudos to him; I think g95's quad support also increased the demand to
implement it in gfortran as well.
** That Andy does not use __float128 is not surprising; I do not know
how good the support was in GCC 4.0/4.1 and for many i?86/x86-64 targets
__float128 support was only added in the last days because of gfortran's
needs.