Plan for implementation of Fortran IEEE modules

[FX]

> I can't say that I am entirely happy with your effort, because the problem
> is that having the procedures available will encourage people to trust
> the IEEE features, and the real problems are in the optimisation and code
> generation.  In particular, there will be pressure to remove optimisations
> and not add new ones because of perceived semantic conflicts - we have
> seen this very badly in the C world.

I understand that this is tricky, probably too tricky to be implemented at 100% in GCC or any compiler in current state. But I do believe that the IEEE modules provide some useful functionality that is otherwise not availble to our users (e.g., in the handling of signed zeros, the generation of NaNs and infinities), at least not in a portable way. Thus, I think that having a imperfect IEEE implementation is better than waiting until we can provide a perfect complete implementation (which could very well be “never”).

Obviously, I welcome all feedback on this implementation that I am now developing. gfortran faces a harder task than other compilers in implementing this support, because it runs on a large variety of targets and has to work as a cross-compiler. What I currently aim for is:

  1. An implementation that is implemented library-side, i.e. as an external module bundled with the compiler (like the much simpler OpenMP module) rather than having the front-end handling everything and directly generating code (like we do for ISO_C_BINDING). This enables us to tap into feature-detection mechanisms of the library, which are not currently available within the front-end.

  2. Then add specific front-end code to handle cases that cannot be deal with on the library side. Use of IEEE_SELECTED_REAL_KIND in constant expressions is the most glaring one, but there are surely others. One issue which I realized recently is that user procedures are required to save the FPU rounding/halting modes on entry and restore them on exit (see my post today on comp.lang.fortran). There surely will be others.

  3. Document the generic GCC compilation options that are compatible with IEEE support (they are possibly target-dependent). If need be, add a Fortran-specific option (-fbest-ieee-support) that switches them on.

  4. Have people field-test all this, and watch bugs trickling in. Rinse and repeat.


I’ve currently making good progress on #1, and I think I can reasonably aim at a first patch for review later this month. With some help (my front-end-foo has rusted), handling IEEE_SELECTED_REAL_KIND in the front-end should not take much time. The rest of #2 will have to wait a bit more.

So: gfortran maintainers, interested users, I’m looking for feedback on this plan.

FX