This is the mail archive of the
mailing list for the GCC project.
Re: [gfortran] I/O of large integer and real kinds
- From: FX Coudert <fxcoudert at gmail dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: patch <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Tue, 07 Jun 2005 21:38:32 +0200
- Subject: Re: [gfortran] I/O of large integer and real kinds
- References: <42A4C151.email@example.com> <20050607191724.GE27034@redhat.com>
+ *((GFC_REAL_4 *) dest) =
strtof (buffer, NULL);
- (float) strtod (buffer, NULL);
+ (GFC_REAL_4) strtod (buffer, NULL);
If you're going to pretend that GFC_REAL_4 is anything besides float,
then you need to use some mechanism to select the proper libc routine.
This is going to be all over libgfortran.
That's right. But this problem has very deep consequences for
libgfortran (basically, there's not much left if you remove assumptions
such as this). I intend to fix this in a distant future (or will happily
see this fixed by someone else), but this problem alread exists and is
orthogonal to this patch (before my patch, GFC_REAL_4 is typedef-ed to
be float, and my patch doesn't change that).
There are targets for which both real10 and real16 exist. Obviously,
only one of them corresponds to long double. amd64-linux is one of
these; ia64-hpux is another.
That is a interesting question. Then there is no bijective
correspondance between fortran kind and C type, and we will need some
more imagination... What are C types for real(10) and real(16) on ia64-hpux?
As for amd64-linux, real(16) does not seem available (unless there is a
difference between amd64 and x86_64):
$ ./bin/gfortran -v
Using built-in specs.
Configured with: ../gcc/configure
Thread model: posix
gcc version 4.1.0 20050607 (experimental)
$ ./bin/gfortran a.f90
In file a.f90:2
real(16) :: y
Error: Kind 16 not supported for type REAL at (1)
This applies again when it comes to your shell script that creates
Yes. What we really need is a *general* way to build a list of possible
fortran kinds (this is easy and done by my shell script) and the
associated C types (difficult), library functions (not so difficult when
C types are done).
I've asked the list for ideas on how to do this twice, and no real idea
has emerged. The patch I propose does not change the existing behavior
of libgfortran, it only extends its behavior.
I'm looking forward to get both support for large kinds and correct
general handling of available kinds in libgfortran, but I think we need
to get the once at a time.