------- Comment #5 from schnetter at aei dot mpg dot de 2005-12-15 21:44
-------
Subject: Re: Would like to access "long double" equivalent type as real*16
On Dec 15, 2005, at 14:34:47, kargl at gcc dot gnu dot org wrote:
> ------- Comment #4 from kargl at gcc dot gnu dot org 2005-12-15
> 20:34 -------
> (In reply to comment #3)
>> I was not suggesting to introduce a new datatype for real*16, but
>> that
>> the same type that is used for long double in C is available as
>> real*16
>> in Fortran, if the option -m128bit-long-double is used.
>
> C's long double type is mapped to REAL(kind=10) on ia32.
I know.
> You
> can read the top of trans-type.c to see how kinds are determined
> and perhaps learn why real*16 will never happen on ia32.
That I don't understand. I assume that changing the statement
kind = (GET_MODE_PRECISION (mode) + 7) / 8;
to something like
if (mode == TYPE_MODE(float_mode))
kind = sizeof(float);
else if (mode == TYPE_MODE(float_double))
kind = sizeof(double);
else if (mode == TYPE_MODE(float_long_double))
kind = sizeof(long double);
would do the trick. This obviously changes the intent of the code,
which is clearly stated in the comment block above, and it's not up
to me to decide whether this should be done. But that change does
not seem impossible from a technical point of view.
Let me assume for the moment that sizeof(float)==4 and sizeof(double)
==8; most architectures will have this, and if not, one can special-
case these non-IEEE platforms. Architectures that don't support
real*4 and real*8 will create much Fortran trouble anyway, even if
the compiler conforms perfectly to the Fortran standard.
The only case in which this new mechanism then fails is if sizeof
(double) == sizeof(long double), but long double and double are
actually different types. This case can also easily be caught, and
one can use a kind different from 8 for the equivalent of long double
in this case.
>> This request is not outlandish --- there are other compilers that
>> support IEEE's 10 byte type as real*16, introducing 6 bytes of
>> padding.
>
> The other compilers have more than 5 unpaid volunteers working
> full time of said compilers.
Sorry. With "outlandish" I did not mean to imply that someone should
implement that; I would never request that. I meant whether the
gfortran developers would accept such a patch, which I didn't want to
prepare before I know whether there is a chance that it would be
accepted.
>> It is customary in FORTRAN 77 to name data types after the number of
>> bytes that they use.
>
> "Customary" is not a part of any version of Fortran standard. In
> fact, REAL*n isn't in any version of the standard.
I know. Nevertheless there exists much code that uses that. This is
clearly a case where GFortran has the freedom to choose the kind
numbers it assigns to its real types.
>> While it is not necessary that GFortran follows this convention, it
>> would simplify porting FORTRAN 77 applications to GFortran, and I
>> would like to see that feature.
>
> Porting code involves more than flipping a switch. Assuming
> REAL*16 means REAL(KIND=10)+6 bytes of padding for all codes that
> have a REAL*16 is just plain stupid.
I did not assume that! I would like (I don't assume) to have a 16
byte data type that is called real*16. I only cited the padding
because you suggested that real*16 would require software emulation
of a new type, which it does not do if one uses padding.
> But, you have the source code
> and patches to implement the feature are always welcomed. I, however,
> think you've greatly under estimated the task.
I had somehow assumed that it would be only a matter of changing the
kind numbers that are assigned to the real types that gfortran
already supports. I assumed that a patch similar to the lines I
suggest above would be sufficient. Is there something big that I
overlooked?
Obviously the suggested change would be improved to ensure to
actually use different kind numbers for all supported hardware
floating types, and it can also be improved to continue to support
real*10 and real*16 at the same time for the same type if that is
desired.
Thank you for your comments. I do not know much about the internal
representation of types in gcc, and your comments seem to indicate
that I would encounter a sleeping beast. When I last looked at
real*16, there were big problems with the I/O library in gfortran,
and I also don't know whether these have been solved in the mean
time. I think it just mapped long double to double, which would kind
of defeat the purpose of using long double in the first place.
-erik
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629
