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

[FX Coudert]

>>+      *((GFC_REAL_4 *) dest) =
>> #if defined(HAVE_STRTOF)
>> 	strtof (buffer, NULL);
>> #else
>>-	(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
         1
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.

FX