(j3.2006) was: Asymmetry of REAL, CMPLX intrinsics - decimal floats

Bill Long longb
Thu Jan 10 11:49:57 EST 2008

Jim Xia wrote:
> > And the vendors are still complaining that there's too much to do.
> Yes, there's too much to do already.  Breaking the 
> backward-compatibility is always a bad thing to vendors, not to 
> mention the proposed change brings no new functionality to these two 
> intrinsics.  Use KIND argument in cmplx to solve Van's problem.  I'll 
> be happy to remove the radix feature in selected_real_kind, which is 
> really not done right :-)

I used to be in favor of removing this as well.  Malcolm's arguments 
convinced me that having two competing formats does not affect whether  
selected_real_kind with radix= is useful.  We have had similar 
environments in the past (non-ieee formats such as legacy Cray, DEC, 
etc.)  and selected_real_kind worked just fine.  It has been recently 
pointed out to me that the latest AMD ABI requires  support for  decimal 
floating point (Intel format, I assume).  I sense that this is coming 
whether we want it or not,  and the Fortran 2008 standard is the place 
to add the support.  If we wait until the next revision, we'll be quite 
a bit behind the curve.  Even though the proprietary hardware targeted 
by our compiler does not support decimal floats, I've none the less put 
in a request to the compiler writers to reserve two KIND values for use 
in the future  (3 for 32-bit decimal floats, and 6 for 64-bit.)

If you are convinced the current spec is not done right, I'd refer to 
fix it, rather than deleting the feature.


Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120


More information about the J3 mailing list