This is the mail archive of the
mailing list for the GCC project.
Re: [fortran,patch] Complete front-end support for __float128
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: FX <fxcoudert at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 26 Aug 2010 16:45:35 +0200
- Subject: Re: [fortran,patch] Complete front-end support for __float128
- References: <D8976839-A544-4F4C-97E4-FF9F28451F16@gmail.com>
On Thu, Aug 26, 2010 at 4:39 PM, FX <email@example.com> wrote:
> So, this is my patch for full front-end support for __float128 in gfortran. What remains to be done here, and what this patch does, is:
> ?-- add the knowledge of this type to the front-end (new gfc_real_info member, for example)
> ?-- allow the user to enable it, with a new option -fsoft-float
> ?-- allow the front-end to generate correct function calls for intrinsics: use builtins for float, double and long double, and build external function decls for __float128 functions
> I think the patch is rather small. It is very low-risk, as everything new is hidden behind the new option (whose name may be too close to -msoft-float, which has a totally different meaning; I have no better idea). To be sure, I regtested everything on x86_64-linux, both with -m32 and -m64, and both with -msoft-float and without. I found only one test that needed to be adjusted (random_seed_1.f90 wasn't taking into account the possibility of the compiler having both real(kind=10) and real(kind=16)).
Why do you need a flag at all? Simply support real(kind=16).
And why should having both real(kind=10) and real(kind=16) be a problem?