[fortran,patch] Complete front-end support for __float128

[FX <fxcoudert at gmail dot com>]

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)).

How to test the new front-end support, without library support in yet (I'm currently cleaning that library patch, which I believe is now feature-complete)? I attached three programs, which you can check in the following way:

  -- a1.f90 tests selected_real_kind, both front-end (which works) and library version (which fails currently). You can compile it with and without -fsoft-float to see the difference.
  -- a2.f90 should be compiled into an object file. You can see that the appropriate quad-float external functions are called: sqrtq(), ynq() and cosq(). I also check that real(kind=10) functions are still called correctly (jnl() and sinl(); sqrtl() is generated inline)
  -- a3.f90 shows frexpq(), fabsq() and scalbnq() calls are generated from trans-intrinsic, when translating the RRSPACING Fortran intrinsic.


I believe it's easier (and makes more sense) to include proper testcases when I submit the patch for library support, so that everything is tested at once.


So, tested as indicated above (and previous regtest on x86_64-darwin also). I'd welcome a regtest on a target that has no __float128, like powerpc.

OK to commit to trunk?

FX






PS: Not related to this patch exactly, but probably informative for developpers tackling this issue in the future. Even with this patch, the front-end is still not quite generic in its handling of floating-point types. The current hypotheses made are:
  -- there are at least two floating-point types, which correspond to C float and double; double is twice as wide as float
  -- if the target's "long double" type is wider than "double", then we have a third floating-point type
  -- if "long double" is smaller than 128 bits, and the targets supports a __float128 type, and the user asked for it (-fsoft-float), we have a fourth floating-point type

We could move it to be even more generic than this (something like "there are floating-point modes, and some of them correspond to existing C types, which have designated builtins; the others use library functions with a given suffix), but it seems quite a bit of extra work for (currently) no particular reason.

Attachment: float128_frontend.ChangeLog
Description: Binary data

Attachment: float128_frontend.diff
Description: Binary data

Attachment: float128_testsuite.ChangeLog
Description: Binary data

Attachment: float128_testsuite.diff
Description: Binary data

Attachment: a1.f90
Description: Binary data

Attachment: a2.f90
Description: Binary data

Attachment: a3.f90
Description: Binary data