Testing __float128 [Cygwin]

[Tobias Burnus]

  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.