[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-15 05:04 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-12-15 05:04:56
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[kargl at gcc dot gnu dot org]

------- Comment #2 from kargl at gcc dot gnu dot org  2005-12-15 17:41 -------
Gfortran will never support a real*16 data type on IA32 hardware.
This would require software emulation of all of basic floating-point 
arthimetic as well as implementation/modification of all intrinsic
procedures that accept real data types and revamping the IO subsystem.
I doubt that this will happen in my life time.

This PR should be closed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[schnetter at aei dot mpg dot de]

------- Comment #3 from schnetter at aei dot mpg dot de  2005-12-15 19:39 -------
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.  This request is not outlandish ---
there are other compilers that support IEEE's 10 byte type as real*16,
introducing 6 bytes of padding.  This aligns the data with the cache lines and
can increase performance.

It is customary in FORTRAN 77 to name data types after the number of bytes that
they use.  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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[kargl at gcc dot gnu dot org]

------- 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.  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.

> 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.

> 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.

> 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.  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.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[schnetter at aei dot mpg dot de]

------- 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

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[tobias dot burnus at physik dot fu-berlin dot de]

------- Comment #6 from tobias dot burnus at physik dot fu-berlin dot de  2006-05-24 22:11 -------
> Gfortran will never support a real*16 data type on IA32 hardware.
> This would require software emulation of all of basic floating-point
> arthimetic

This is what Intel's Fortran Compiler does - it emulates quads in software on
IA32/EM64T/Itanium. Steve Lionel mentions another possibilty:
"IBM has an odd implementation where they use two doubles with offset
exponents. It's fast but it isn't a uniform type and doesn't give you extended
range, so it's useless for a lot of what people use higher precision types
for."
See
http://softwareforums.intel.com/ids/board/message?board.id=5&message.id=17632

g95, NAGWare f95, Pathscale and Portland's pgf95 all fail to compile real(16)
[most of them use GCC as backend, though] on AMD64.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[fxcoudert at gcc dot gnu dot org]

------- Comment #7 from fxcoudert at gcc dot gnu dot org  2006-06-21 16:46 -------
(In reply to comment #5)
>         else if (mode == TYPE_MODE(float_long_double))
>                 kind = sizeof(long double);

sizeof(long double) is the size of a long double for the host, not on the
target.

> 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.

To have the answer to that question, you'd need to ask on the mailing-list,
detailing the implications of such a change (pros and cons).

> 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?

I think the whole library interaction would change, requiring a multilib
libgfortran. Plus, you'd probably need good interaction with the target's libm.

> 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.

No, the library should be completely working. Although I'm not sure many people
use real(kind>8), so the testing may not be very wide.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629

[Bug fortran/22629] Would like to access "long double" equivalent type as real*16

[fxcoudert at gcc dot gnu dot org]

------- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-07-28 20:51 -------
I do understand that it would be easier for you to "tweak" the kind numbers
used by gfortran to accomodate old code, but there really is a problem with
doing so: it will, for example, clash with the prospected use of real(kind=16)
for software floating-points, which we plan to incorporate into gfortran.

After some discussion on IRC, I'm closing this as WONTFIX, unless something
thinks of a way to avoid the clash and step forward to actually implement this
enhancement. In that later case, please REOPEN the bug.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629