Re: [RFC] Generalizing the library to arbitrary floating-point modes

[Tobias dot Schlueter at Physik dot Uni-Muenchen dot DE]

Quoting François-Xavier Coudert <fxcoudert@gmail.com>:
> I'd like to make the library much more general in the way it handles
> floating-point modes. Right now, it's limited to the intersection of
> {real kinds 4, 8, 10 and 16 (but not both 10 and 16)} and {C types
> float, double, long double}. Moreover, it's done in a very ad hoc way.
> What I'd like to have is the following:

Do you plan to implement mathematical functions where the library doesn't
provide them (say, sqrt(1._10) on an architecture where long double corresponds
to real(16))?

>   4. (optionnal) the files generated from m4 are reworked so that
> there aren't so many files (I can tell you, on systems with slow shell
> or slow forking, libgfortran takes *ages* to compile). Moreover, we
> would then only have one place to change when adding a new real kind.

I was wondering if it wasn't possible to use some autoconf magic to not generate
those files in cases where there are no corresponding datatypes (i.e. all the
*16.* files on i686).  Of course that wouldn't solve the underlying problem
that there are a lot of files being generated, it would only reduce their
number.  A possible solution to the problem of generating many files might be
the approach taken in intrinsics/mvbits.c, which could probably also be
replicated in m4, by writing all specific versions into a single file. 
(Personally, I find cpp a more readable language than m4.)

- Tobi