This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gfortran] I/O of large integer and real kinds

+      *((GFC_REAL_4 *) dest) =
#if defined(HAVE_STRTOF)
	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.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/var/tmp/gfortran-20050607/irun --enable-languages=c,f95
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
the typedefs.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]