[RFC] Generalizing the library to arbitrary floating-point modes
Tobias.Schlueter@Physik.Uni-Muenchen.DE
Tobias.Schlueter@Physik.Uni-Muenchen.DE
Wed Nov 30 16:38:00 GMT 2005
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
More information about the Fortran
mailing list