[gfortran,ping] support for large kinds in front-end and library

FX Coudert fxcoudert@gmail.com
Tue Sep 13 07:33:00 GMT 2005


>>>#ifndef HAVE_ATAN2L
>>>long double atan2l (long double x) { return (long double) atan2 ((double)
>>>x); }
>>>#endif 
>>
>>IMHO this is sufficient.
> 
> Yes, this is sufficient to allow FX to commit his patch.
> However, we need a HUGE DISCLAIMER in the documentation
> that states gfortran may have unacceptably poor REAL(10)
> intrinsics procedures.  Of course, we can hide behind the
> "result has a value equal to a processor-dependent approximation
> to ... " language found throughout 13.14.
> 
>    real(10) :: x = 1.e1000
>    print*, log10(x)
>    end

 From my point of view, it is better to have the compiler error out at 
link-time for such a program. That is the current behaviour, and I can 
add this (in fact, I'm right now testing my patch) to the library, so 
that we can have situations like, for generated/_acos_r10.F90:

#include "config.h"
#include "kinds.inc"

#if defined (HAVE_GFC_REAL_10)
#ifdef HAVE_ACOSL

elemental function specific__acos_r10 (parm)
    real (kind=10), intent (in) :: parm
    real (kind=10) :: specific__acos_r10

    specific__acos_r10 = acos (parm)
end function

#endif
#endif
------------------------------------------

or, for generated/nearest_r10.c:

#if defined (HAVE_GFC_REAL_10) && defined (HAVE_COPYSIGNL) && defined 
(HAVE_NEXTAFTERL)

....

#endif


That, IMHO, would be better behaviour. Of course, the perfect behaviour 
would be to have the front-end not accept kinds for which library 
support is not complete. But I'm not going to try and do that :(

-- 
FX



More information about the Fortran mailing list