This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [fortran,patch] Higher-level access to floating-point builtins
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>
- Cc: FX <fxcoudert at gmail dot com>, fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Fri, 11 Jun 2010 09:24:47 -0700
- Subject: Re: [fortran,patch] Higher-level access to floating-point builtins
- References: <20100611154020.GB18233@physik.fu-berlin.de>
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