[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-05-13 14:49:52 UTC ---
On Fri, May 13, 2011 at 10:10:42AM +0000, burnus at gcc dot gnu.org wrote:
> 
> +  if (mpfr_nan_p (x->value.real) != 0 || mpfr_inf_p (x->value.real) != 0)
> +    {
> +      mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
> +      if (gfc_option.allow_std & (GFC_STD_F2008|GFC_STD_F2003))
> +         return result;
> +      return range_check (result, "FRACTION");
> +    }
> +
> 
> Regarding the coding:
> * if (gfc_option.allow_std & (GFC_STD_F2008|GFC_STD_F2003))
>   Better: "gfc_option.allow_std & GFC_STD_F2003)" - later standards imply
>   earlier ones.

OK.

> * mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
>   Better: mpfr_set_nan (result->value.real);

As Thomas points out, the Standards that it X is an IEEE NaN,
then FRACTION(X) is that NaN.  The mpfr_set() should be simply
copying the NaN into the result [1].  mpfr_set_nan() may not be
the same NaN.  From the ieee754 standard (when Fortran 2003/2008)
were written, we have for a 32-bit floating point NaN

 If e = 255 and f != 0 , then v is NaN regardless of s

Here, e is a biased exponent and f is the significand.  Therefore,
there are 2**24 possible values for f and hence NaN.

[1] Arg.  I just looked at a reduced test based on Thomas code.  I
get

troutmask:sgk[214] gfc4x -o z g1.f90 && ./z
       NaN 7FD00000        NaN 7FD00000           0
       NaN 7FD00000        NaN 7FC00000           0

so the rounding with mpfr_set seems to be effecting the copying
of the x into the result.

> I still miss that -frange-check is mentioned in the error messages produced by
> range_check() - and I am not really convinced that (a) the error should be
> conditional on -std=f95 and (b) that having a -frange-check enabled by default
> is a bad idea. I think many code problems have been found that way - and if the
> flag is mentioned in the error message, those few codes which need it, can
> simply disable the check.

What to do about range checking is a different issue.  Putting
info about -frange-check in the error message would certainly
pre-empt the assumption that people actually read the documentation
provided with their compiler.