[fortran,patch] Higher-level access to floating-point builtins

Steve Kargl sgk@troutmask.apl.washington.edu
Fri Jun 11 16:53:00 GMT 2010


On Fri, Jun 11, 2010 at 05:40:20PM +0200, Tobias Burnus wrote:
> Hi Fabri?e-Xavier,
> 
> FX wrote:
> > In the front-end is deeply hardcoded the universal truth that
> > real(kind=4) corresponds to the C "float" type, real(kind=8) to
> > the C "double", and that one and only one of real(kind=10) and
> > real(kind=16) exists, which corresponds to the "long double" type.
> > [...] The goal of this patch is to get rid of this, in order to:
> >   1. simplify the code
> 
> Nit:
> +      /* For now, we assume that if real(kind=10) exists, it is long double.
> +	 Later, we will deal with __float128 and break this assumption.  */
> 
> I think that should be kind=16.
> 

IIRC, it can be either.  It depends on the target.  If
REAL(10) matches long double, then that's what is used.  If
REAL(16) matches long double, then that's what is used.  Until
FX finishes his patch, REAL(10) and REAL(16) cannot co-exist
in gfortran.

> Looks fine to me - and it is certainly better not to assume the
> real(kind=4/8/(10,16)) = C's float/double/long double correspondence.

This does bring to mind the question of C interop.  Does
gfortran need to do anything special with mapping a software
floating point type to something in C?

-- 
Steve



More information about the Gcc-patches mailing list