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

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

[thenlich at users dot sourceforge.net]

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

           Summary: FRACTION und EXPONENT return invalid results for
                    infinity/NaN
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: thenlich@users.sourceforge.net


program test_fractnan
    real, parameter :: pinfp = transfer(z'7F800000', 0.0)
    real, parameter :: ninfp = transfer(z'FF800000', 0.0)
    real, parameter :: nanp = transfer(z'7FD00000', 0.0)
    real, parameter :: zerop = 0.0
    real :: nan = nanp, pinf = pinfp, ninf = ninfp, zero = zerop

    print 100, zero,  zero,  fraction(zero),  fraction(zero),  exponent(zero)
    print 100, zerop, zerop, fraction(zerop), fraction(zerop), exponent(zerop)
    print 100, nan,   nan,   fraction(nan),   fraction(nan),   exponent(nan)
    print 100, nanp,  nanp,  fraction(nanp),  fraction(nanp),  exponent(nanp)
    print 100, ninf,  ninf,  fraction(ninf),  fraction(ninf),  exponent(ninf)
    print 100, ninfp, ninfp, fraction(ninfp), fraction(ninfp), exponent(ninfp)
    print 100, pinf,  pinf,  fraction(pinf),  fraction(pinf),  exponent(pinf)
    print 100, pinfp, pinfp, fraction(pinfp), fraction(pinfp), exponent(pinfp)
100 format (f10.5,1x,z8,1x,f10.5,1x,z8,1x,i11)
end program test_fractnan

Result:
   0.00000        0    0.00000        0           0
   0.00000        0    0.00000        0           0
       NaN 7FD00000        NaN 7FD00000           0
       NaN 7FD00000    0.00000        0           0
 -Infinity FF800000  -Infinity FF800000           0
 -Infinity FF800000        NaN 7FC00000 -2147483645
  Infinity 7F800000   Infinity 7F800000           0
  Infinity 7F800000        NaN 7FC00000 -2147483645

Expected result (-std=f2003):
   0.00000        0    0.00000        0           0
   0.00000        0    0.00000        0           0
       NaN 7FD00000        NaN 7FD00000  2147483647
       NaN 7FD00000        NaN 7FD00000  2147483647
 -Infinity FF800000  -Infinity FF800000  2147483647
 -Infinity FF800000  -Infinity FF800000  2147483647
  Infinity 7F800000   Infinity 7F800000  2147483647
  Infinity 7F800000   Infinity 7F800000  2147483647

Expected result (-std=f2008):
   0.00000        0    0.00000        0           0
   0.00000        0    0.00000        0           0
       NaN 7FD00000        NaN 7FD00000  2147483647
       NaN 7FD00000        NaN 7FD00000  2147483647
 -Infinity FF800000        NaN 7FC00000  2147483647
 -Infinity FF800000        NaN 7FC00000  2147483647
  Infinity 7F800000        NaN 7FC00000  2147483647
  Infinity 7F800000        NaN 7FC00000  2147483647

EXPONENT(X)
Fortran 2003/2008:
If X is an IEEE infinity or NaN, the result has the value HUGE (0).

FRACTION(X)
Fortran 2003:
If X is an IEEE infinity, the result is that infinity. If X is an IEEE NaN, the
result is that NaN.

Fortran 2008:
If X is an IEEE NaN, the result is that NaN. If X is an IEEE infinity, the
result is an IEEE NaN.

Bug 1:
The program does not compile without -fno-range-check.

Bug 2:
Different results are returned for a variables with values of NaN/Infinity and
compile-time constants NaN/Infinity.

Bug 3:
EXPONENT should be HUGE(0)=2147483647 for NaN/Infinity.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-05-12 16:09:39 UTC ---
(In reply to comment #0)
> 
> Bug 1:
> The program does not compile without -fno-range-check.
> 

Can you explain why you think that this is a bug?

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

[thenlich at users dot sourceforge.net]

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

--- Comment #2 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-05-12 17:34:27 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > 
> > Bug 1:
> > The program does not compile without -fno-range-check.
> > 
> 
> Can you explain why you think that this is a bug?

I consider it a bug because the result of the expressions FRACTION(Infinity)
and FRACTION(NaN) is defined by the Fortran standard, so the compiler should
not throw an error on simplifying them.

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).

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-12 17:49:25 UTC ---
(In reply to comment #2)
> 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.

However, I have to admit that the error message should mention
-fno-range-check; currently, it does not.

[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 #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-05-12 18:21:46 UTC ---
On Thu, May 12, 2011 at 05:53:10PM +0000, thenlich at users dot sourceforge.net
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
> 
> --- Comment #2 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-05-12 17:34:27 UTC ---
> (In reply to comment #1)
> > (In reply to comment #0)
> > > 
> > > Bug 1:
> > > The program does not compile without -fno-range-check.
> > > 
> > 
> > Can you explain why you think that this is a bug?
> 
> I consider it a bug because the result of the expressions FRACTION(Infinity)
> and FRACTION(NaN) is defined by the Fortran standard, so the compiler should
> not throw an error on simplifying them.
> 
> 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).
> 

You're looking at the wrong standard.  Gfortran is a Fortran
95 compiler (yes, it has many F03 and F08 extensions).  The
Fortran 95 standard states:

13.14.38   FRACTION(X)

  Result Value.  The result has the value X*b**(-e), where
  b and e are as defined in 13.7.1 for the model representation
  of X.  If X has the value zero, the result has the value zero.

Neither NaN nor +-Inf can be represented as a model number.

[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 #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.

[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.

[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 #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-05-12 20:10:19 UTC ---
Here's a better patch that gets the warning/error
messages correct.

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

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

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-12 20:36:05 UTC ---
(In reply to comment #7)
> +      return range_check (result, "FRACTION");

Can we additionally add to the range_check() error messages a note like "This
check can be disabled with the option -fno-range-check"? We already did so at
several places. I think without, one does not know that one can easily disable
it.

An alternative would be to switch to the middle-end way of showing warning
messages:
   warning: unused variable 'x' [-Wunused-variable]

Analogously, the error could then be "[-frange-check]".

[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 #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-05-12 20:54:38 UTC ---
Forgot the diff

Index: simplify.c
===================================================================
--- simplify.c  (revision 173705)
+++ simplify.c  (working copy)
@@ -2328,6 +2328,14 @@ 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);
+      if (gfc_option.allow_std & (GFC_STD_F2008|GFC_STD_F2003))
+         return result;
+      return range_check (result, "FRACTION");
+    }
+
   if (mpfr_sgn (x->value.real) == 0)
     {
       mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);

[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 #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-05-12 20:53:37 UTC ---
On Thu, May 12, 2011 at 08:40:48PM +0000, burnus at gcc dot gnu.org wrote:
> (In reply to comment #7)
> > +      return range_check (result, "FRACTION");
> 
> Can we additionally add to the range_check() error messages a note like "This
> check can be disabled with the option -fno-range-check"? We already did so at
> several places. I think without, one does not know that one can easily disable
> it.
> 
> An alternative would be to switch to the middle-end way of showing warning
> messages:
>    warning: unused variable 'x' [-Wunused-variable]
> 
> Analogously, the error could then be "[-frange-check]".
> 

I worked up the following patch.  It now silently accepts
fraction() for +-inf and nan for -std=gnu,f2003,f2008.  If
one uses -std=f95, you get a bunch of noise.  I'll finish
a patch on Saturday.

EXPONENT() is going to be a little more work.  When simplication
does not apply, gfortran uses something like

      integer(kind=4) D.1559;
      integer(kind=4) D.1558;

      __builtin_frexpf (nan, &D.1558);
      D.1559 = D.1558;
      _gfortran_transfer_integer_write (&dt_parm.2, &D.1559, 4);

to grab the fraction and exponent.  For nan and +-inf, 
D.1558 is 0.

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

[thenlich at users dot sourceforge.net]

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

--- Comment #11 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-05-13 09:13:01 UTC ---
Mind the change between F2003 and F2008:
F2003:
FRACTION(+Inf) = +Inf
FRACTION(-Inf) = -Inf

F2008:
FRACTION(+Inf) = NaN
FRACTION(-Inf) = NaN

And I think what "If X is an IEEE NaN, the result is that NaN." means is:
IF ISNAN(X) FRACTION(X) = X
which is different from
IF ISNAN(X) FRACTION(X) = Z'7FC00000'

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

[burnus at gcc dot gnu.org]

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

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-05-13 09:42:02 UTC ---
(In reply to comment #11)
> Mind the change between F2003 and F2008:
> F2003:
> FRACTION(+Inf) = +Inf
> 
> F2008:
> FRACTION(+Inf) = NaN

See http://j3-fortran.org/doc/year/07/07-200r1.txt for that change (cf. also
http://www.j3-fortran.org/doc/meeting/186/08-287r2.txt ).

However, I think it makes sense to stick to the F2008 value - and ignore F2003.


+  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.
* mpfr_set (result->value.real, x->value.real, GFC_RND_MODE);
  Better: mpfr_set_nan (result->value.real);


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.


Side note: If I understand F2003/F2008's IEEE support correctly (that's a big
if): You need to have IEEE_EXCEPTIONS or IEEE_ARITHMETIC loaded *in the scoping
unit*, if you want to use IEEE 754 features. Additionally, a query for
IEEE_SUPPORT_INF and/or IEEE_SUPPORT_NAN had to return .true. in order that
those can be expected to be supported. In that sense: As the program does not
load a IEEE module, it cannot use NAN/INF and the compile-time error is
standard conforming ;-)

[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.

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

[kargl at gcc dot gnu.org]

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

--- Comment #14 from kargl at gcc dot gnu.org 2011-05-22 23:02:01 UTC ---
Created attachment 24333
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24333
patch for simplification

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

[kargl at gcc dot gnu.org]

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

--- Comment #15 from kargl at gcc dot gnu.org 2011-05-22 23:03:22 UTC ---
(In reply to comment #14)
> Created attachment 24333 [details]
> patch for simplification

I doubt that I'll be able to go beyond this.  I'm
not clever enough nor fluent enough with trees to
fix the issues in trans-intrinsics.c.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-01-07
     Ever confirmed|0                           |1

--- Comment #17 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
What is the fate of the patches in comments 6, 7, 10, ... ?

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

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
                 CC|                            |fxcoudert at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |fxcoudert at gcc dot gnu.org

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

[fxcoudert at gcc dot gnu.org]

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

--- Comment #18 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Author: fxcoudert
Date: Sat Oct 11 16:57:32 2014
New Revision: 216120

URL: https://gcc.gnu.org/viewcvs?rev=216120&root=gcc&view=rev
Log:
    PR fortran/48979

    * simplify.c (gfc_simplify_atan): Use mpfr_zero_p to check for zeros.
    (gfc_simplify_log): Likewise.
    (gfc_simplify_scale): Likewise.
    (gfc_simplify_exponent): Handle infinities and NaNs.
    (gfc_simplify_fraction): Handle infinities.
    (gfc_simplify_rrspacing): Handle signed zeros and NaNs.
    (gfc_simplify_set_exponent): Handle infinities and NaNs.
    (gfc_simplify_spacing): Handle zeros, infinities and NaNs.

    * gfortran.dg/ieee/intrinsics_1.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/ieee/intrinsics_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/simplify.c
    trunk/gcc/testsuite/ChangeLog

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

[fxcoudert at gcc dot gnu.org]

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

--- Comment #19 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Author: fxcoudert
Date: Sun Oct 19 20:49:27 2014
New Revision: 216443

URL: https://gcc.gnu.org/viewcvs?rev=216443&root=gcc&view=rev
Log:
    PR fortran/48979

    * trans-const.c (gfc_build_nan): New function.
    * trans-const.h (gfc_build_nan): New prototype.
    * trans-intrinsic.c (gfc_conv_intrinsic_exponent): Handle special
    values.
    (gfc_conv_intrinsic_minmaxval): Use gfc_build_nan.
    (gfc_conv_intrinsic_fraction): Handle special values.
    (gfc_conv_intrinsic_spacing): Likewise.
    (gfc_conv_intrinsic_rrspacing): Likewise.
    (gfc_conv_intrinsic_set_exponent): Likewise.

    * gfortran.dg/ieee/intrinsics_2.F90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/ieee/intrinsics_2.F90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-const.c
    trunk/gcc/fortran/trans-const.h
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/testsuite/ChangeLog