[RFC] Support of IEEE modules, first draft for comments

[FX]

Hi all,

Here’s a first draft of a patch adding the IEEE modules (chapter 14 of F2003 and F2008) to gfortran. I’ll comment below on the implementation choices made, and what this patch does and does not implement.

** Implementation choices.

Full IEEE support is very complex, and will require cooperation between front-end, middle-end, and libc. Getting every aspect covered is clearly a multi-year project, which will have to be tackled with middle-end and target-savy developers: IEEE support is not excellent in GCC, see for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

This patch is an attempt to start the ball rolling on the Fortran side, getting incomplete but decent support of some of the features. We won’t achieve something better than what the C compiler does, but we can at least do that. The reason is twofold: 1. a project of this size will not land in a single lengthy patch implementing everything at once, at least not in the current state of gfortran development (bazar vs. cathedral); 2. there are some features that users want to use, and will be able to use alredy, even if we don’t have 100% compliance. 

Now, with this disclaimer in place, here’s the overall scheme:

  — support is implemented on the library side, with the modules written in Fortran (ieee/*.F90) and some functions written in C (libgfortran/ieee/ieee_helper.c) to make use of the compiler-generated builtins which are not exposed by the Fortran front-end
  — target-specific code is put in the existing framework: libgfortran/config/fpu-*.h files, whose “API” I have augmented
  — there is only one part, right now, that is handled in the front-end: IEEE_SELECTED_REAL_KIND needs to be simplified in constant expressions, which is handled in gcc/fortran/expr.c
  — over time, I expect that some more support is put in the front-end, possibly reaching one day the point where all the modules are handled by the front-end (without actual .mod files in the library, like ISO_C_BINDING or ISO_FORTRAN_ENV)


** What is supported exactly?

I’ve written two versions of the target-specific code, one using glibc APIs and one using assembly for all i386/x86_64 targets. On other targets, the modules are simply not built. This is controlled by libgfortran/configure.host, so if targets want to opt out we can simply list them there. If new targets want to opt in (AIX or SYSV APIs, for example), they need to support the new functions in libgfortran/config/fpu-*.h

The IEEE part of the standard allow very flexible support, i.e. there are support query functions by which the implementation can specify what parts of IEEE it does or does not support. I’ve opted for a simple approach there: we declare full IEEE support for the float and double types, but not long double or __float128 (for which target libraries, i.e. libc or libquadmath, are typically of somewhat lower quality). I’m opening to widening our support once we have ironed things out.

One thing we don’t support (as allowed by the standard) is gradual underflow: IEEE_SUPPORT_UNDERFLOW_CONTROL always returns .false., and IEEE_{SET,GET}_UNDERFLOW_MODE trigger an abort. This is because glibc doesn’t have a way to control it, and I didn’t know how to do it in x87/SSE assembly.

All procedures of the IEEE modules are implemented.


** What is not supported?

IEEE support requires cooperation from the front-end. To give one example, the standard indicates that all procedures (that access the IEEE modules) shall restore on exit the floating-point status that they had on entry. Thus, the front-end has to include calls to save (and restore) FPU state at entry (and exit) of user-written procedures.

There are other examples of such requirements. I’ve not made a complete list yet, but here are some:
  — save/restore FPU state (we have the target-specific code in place in libgfortran already, we just need to export it and make the front-end generate the calls)
  — alter code generation by local compiler options, like "-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans”, when IEEE modules are used (just like the C front-end allows specifying specific compilation options for some procedures, using attributes)
  — same as the previous, with finer-grained control (look at note 14.3: "If the program uses an ONLY option on a USE statement to access a particular feature name, the processor shall provide support for the corresponding feature, or issue an error message saying the name is not defined in the module. When used this way, the named constants in the IEEE_FEATURES are similar to what are frequently called command line switches for the compiler.”)

Also, I have not yet done thorough testing of the IEEE arithmetic functions (IEEE_LOGB, IEEE_NEXT_AFTER, IEEE_REM, IEEE_RINT, IEEE_SCALB), but this is the next item on my list.

Finally, I need to write documentation and testsuite coverage. That’s painful, will be done.


** Conclusion

I hope you like it, it’s not perfect but I think it’s an important step in the right direction. Comments on the design and implementation are welcome. My plan is to send out a formal patch by the end of the month.


Cheers,
FX



-------------- next part --------------
A non-text attachment was scrubbed...
Name: ieee.diff
Type: application/octet-stream
Size: 89854 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20131110/5e36205f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ieee_1.F90
Type: application/octet-stream
Size: 3594 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20131110/5e36205f/attachment-0001.obj>