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.
