[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