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

Steve Kargl sgk@troutmask.apl.washington.edu
Mon Sep 12 17:48:00 GMT 2005


On Mon, Sep 12, 2005 at 07:19:20PM +0200, Fran?ois-Xavier Coudert wrote:
> 
> > So, we need to have configure check if these exists in libm,
> > and if not, we need to provide implementations.
> 
> Well, I don't think it's our job to provide implementations.

If we provide REAL(10) (or REAL(16)) data type, then we
must provide "working" Fortran intrinsic procedures (for
some definition of "working").  IIRC, this is a requirement
of the Standard.

> On systems that incompletely support extended floating-points, we can
> support them incompletely. We're not trying to write a complete OS :)

This is a quality of implementation issue.  I can live with your
suggestion below provided that I'm given carte blanche to implement
the slower but higher quality MPFR versions.  Frankly, if I have

   real(10) :: x = 1.e1000
   print *, log(x)
   end

and it prints "+Inf" or "NaN" (not sure what the range error for
double will return), I would find a new compiler to use.

> Or, we could provide degraded functions that use the double type ones:
> 
> #ifndef HAVE_ATAN2L
> long double atan2l (long double x)
> { return (long double) atan2 ((double) x); }
> #endif
> 

Put the above in intrinsics/c99_functions.c and I'll work up
MPFR versions.

Part of my absense in fixing gfortran bugs is due to my detour
in implementing the missing C99 long double function for FreeBSD.
Implementing these functions isn't easy. :-(

-- 
Steve



More information about the Gcc-patches mailing list