[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 #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-05-12 19:18:16 UTC ---
On Thu, May 12, 2011 at 07:03:34PM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
> 
> --- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-05-12 18:47:54 UTC ---
> On Thu, May 12, 2011 at 05:59:44PM +0000, burnus at gcc dot gnu.org wrote:
> > > Whether this really is a bug or not depends on whether one thinks that a
> > > standard-compliant Fortran program should compile without requiring special
> > > options (I do).
> > 
> > So do I - but the question is whether it is standard conforming. NAN and INF
> > are not Fortran numbers, cf. "13.4 Numeric models". Admittedly, IEEE and
> > Fortran model numbers are widely mixed in the standard. However, strictly
> > speaking, the IEEE functionality is only available if the relevant IEEE module
> > is loaded and the feature is marked as supported.
> > 
> 
> >From F2003:
> 
> Page 300:
> 
>    A program is prohibited from invoking an intrinsic procedure
>    under circumstances where a value to be returned in a subroutine
>    argument or function result is outside the range of values
>    representable by objects of the specified type and type parameters,
>    unless the intrinsic module IEEE_ARITHMETIC (section 14) is accessible
>    and there is support for an infinite or a NaN result, as appropriate.
> 
> Page 364:
> 
>    The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and
>    IEEE_FEATURES provide support for exceptions and IEEE arithmetic.
>    Whether the modules are provided is processor dependent.
> 
> 1) Thomas's program does not USE IEEE_ARITHMETIC.
> 2) gfortran does not supply the ieee modules.
> 
> So, calling fraction() with +-Inf and NaN is, I believe,
> technically non-conforming.
> 
> I agree that having consistency between constant-folding
> and runtime results is desirable, I disagree on calling the
> need for -fno-range-check a bug.
> 

Index: simplify.c
===================================================================
--- simplify.c  (revision 173705)
+++ simplify.c  (working copy)
@@ -2328,6 +2328,12 @@ gfc_simplify_fraction (gfc_expr *x)

   result = gfc_get_constant_expr (BT_REAL, x->ts.kind, &x->where);

+  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);
+      return result;
+    }
+
   if (mpfr_sgn (x->value.real) == 0)
     {
       mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);

gives

   0.00000        0    0.00000        0           0
   0.00000        0    0.00000        0           0
       NaN 7FD00000        NaN 7FD00000           0
       NaN 7FD00000        NaN 7FC00000           0
 -Infinity FF800000  -Infinity FF800000           0
 -Infinity FF800000  -Infinity FF800000           3
  Infinity 7F800000   Infinity 7F800000           0
  Infinity 7F800000   Infinity 7F800000           3

fixing exponent is much more involved.