Re: Difference between real(kind=16) and long double

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Sun, Sep 30, 2007 at 11:59:32AM +0100, FX Coudert wrote:
> >Please, don't break gfortran to paper over problems with
> >darwin (and HPUX).  If these arch have broken long double
> >or missing/broken C99 math functions, then so be it.  It
> >seems that you are spending too much time applying wallpaper
> >for targets with little vendor support.
> 
> Otherwise, I understand your concern of keeping gfortran simple (or  
> at least that's what I think your concern is), but I think we need  
> gfortran to behave correctly (at least in most situations) for a wide  
> range of targets.  We are the only compiler that supports such a large  
> range of targets, as well as cross-compilation between them, and  
> that's good. I agree that a balance needs to be kept between range of  
> targets and maintainability, and for this reason I try to keep  
> workarounds self-contained, using autoconf magic and others. If you  
> think they're not enough, please feel free to comment or object to  
> said patches, because I really don't want to hinder gfortran  
> maintainability.

Yes, this is exactly my concern.  If a target does not have an
active gfortran developer, then any hacks may bitrot and we're
left with a maintenance nightmare.  I'd rather disable building
REAL(16) support on oddball platforms than apply hack after
hack.

> >The model numbers and results for the numeric inquiry functions
> >are generated in arith.c.  The numeric inquiry functions, which
> >includes HUGE(), are well-defined in the standard.  If FLT_MAX,
> >DBL_MAX, and LDBL_MAX on a platform do not agree with fortran's
> >HUGE(), then open a bug report with the vendor.  Their float.h
> >is broken.
> 
> trans-types.c has the following comment:
> 
>       if (fmt->pnan < fmt->p)
>         /* This is an IBM extended double format (or the MIPS variant)
>            made up of two IEEE doubles.  The value of the long  
> double is
>            the sum of the values of the two parts.  The most  
> significant
>            part is required to be the value of the long double rounded
>            to the nearest double.  If we use emax of 1024 then we can't
>            represent huge(x) = (1 - b**(-p)) * b**(emax-1) * b, because
>            rounding will make the most significant part overflow.  */
>         gfc_real_kinds[r_index].max_exponent = fmt->emax - 1;
> 
> And I finally found the original mailing-list thread about it: http:// 
> gcc.gnu.org/ml/fortran/2005-09/msg00555.html  At that time, there  
> seemed to be general agreement that huge(0._16) needn't be the same  
> as LDBL_MAX. So, although I don't agree with your statement quoted  
> above (it's not a vendor bug), I agree with the following (I had to  
> sleep on it):

Yeah, I recall being involved in the discussion of the above.  I even
may have been the person who approved the above.  I remember I was not
happy with the above.  

> >Under no circumstance should one change (!isfinte(x))
> >into (!isfinite(x) || x > HUGE || x < HUGE).
> 
> That's true. I think the only way to go is to recognize that the  
> Fortran standard doesn't forbid that there can be floating-point  
> numbers larger than HUGE() which aren't Infinities, and as such are  
> not printed out as +Inf. So, it probably means that our  
> implementation is right but we need only fix the testcase.
> 
> Opinions welcome, everyone,

I think you're right.  The description of HUGE() in the standard
is

   Returns the largest number of the model representing numbers of
   the same type and kind type parameter as the argument.

Note the explicit statement of "model representing numbers".  Other
intrinsics function descriptions typically refer to machine 
representable numbers.  For example, see the description of NEAREST().
I'd suggest xfailing the testcase.

-- 
Steve