[Bug fortran/33296] New: nearest(huge(1.0),1.0) gives an error

[Bug fortran/33296] New: nearest(huge(1.0),1.0) gives an error

[dominiq at lps dot ens dot fr]

The following code:

real x
x = nearest(huge(1.0),1.0)
end

gives

x = nearest(huge(1.0),1.0)
           1
Error: Result of NEAREST overflows its kind at (1)

instead of setting x to +Inf. This bug is also present in GNU F95 version
4.2.1.


-- 
           Summary: nearest(huge(1.0),1.0) gives an error
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin8


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

[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error

[fxcoudert at gcc dot gnu dot org]

------- Comment #1 from fxcoudert at gcc dot gnu dot org  2007-09-04 10:26 -------
I think it's the expected behaviour. Other compilers emit warnings (or nothing)
for this situation or related ones (like x = 2*huge() below), we chose to emit
hard errors that can be bypassed by using -fno-range-check.

  real x
  x = nearest(huge(1.0),1.0)
  x = 2 * huge(1.0)
  print *, x
  end


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |RESOLVED
 GCC target triplet|powerpc-apple-darwin8       |
         Resolution|                            |INVALID


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

[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2007-09-04 12:05 -------
I don't think the PR is invalid:

(1) at least it should go the "enhancement" with the addition of " This check
can be disabled with the option -fno-range-check" as in

print *, huge(0), -2147483648
                            1
Error: Integer too big for its kind at (1). This check can be disabled with the
option -fno-range-check

(2) I think the two cases are totally different:

 huge(0)+1 cannot be represented in the integer model, thus the overflow;

 as soon as the compiler knows INF/NAN (and gfortran does), I think
nearest(huge(1.0),1.0)==+Inf is part of the floating point model and should not
throw even a warning (even with -std=xx -pedantic).

I don't want to start a flame war of this issue, but look at the number of
mails, answers, noise, ..., generated by -2147483648 (note that I did not write
-(2147483648)!-).


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor


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

[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error

[fxcoudert at gcc dot gnu dot org]

------- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-09-04 12:34 -------
(In reply to comment #2)
> (1) at least it should go the "enhancement" with the addition of " This check
> can be disabled with the option -fno-range-check"

We can do that, indeed. Reopening and marking enhancement.

> (2) I think the two cases are totally different:
>  as soon as the compiler knows INF/NAN (and gfortran does), I think
> nearest(huge(1.0),1.0)==+Inf is part of the floating point model and should
> not throw even a warning (even with -std=xx -pedantic).

I think the standard is very clear on that. Quoting F2003 13.7:

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

Unless we have IEEE_ARITHMETIC, we should stick to an error.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |enhancement
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-09-04 12:34:17
               date|                            |


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

[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error

[dominiq at lps dot ens dot fr]

------- Comment #4 from dominiq at lps dot ens dot fr  2007-09-07 08:45 -------
> I think the standard is very clear on that. Quoting F2003 13.7:

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

> Unless we have IEEE_ARITHMETIC, we should stick to an error.

As usual, the standard put the burden on the user only and does not give any
clue about what should be done with violations.  In my opinion there are three
ways to handle them:

(1) Commit suicide (the code not the user!-): in most (all) situations Inf's
and NaN's are coming from exceptions (for 100% of my codes and with probability
1 for the other ones I use, they comes from bug or (inclusive) numerical
instabilities).  On most platforms these exceptions could be traped to give
errors or runtime abort, as done for the memory violations.  This the way I
would like to see implemented by default, since I think it is the only one
making sense for numerical simulations.
In this case -fno-range-check could be a simple way to disable the traping.

(2) Replace the "and" in "... is accessible and there is support ..." by an
"or".  This is the choice of most (all) compilers I have access to, including
gfortran outside this specific issue: there is a couple codes in the gfortran
testsuite testing for Inf and NaN without -fno-range-check (or at least do not
give errors without it).

(3) Bad ones: half-backed solutions, in which sometines you get (1) and
sometimes (2).  This is the present situation of gfortran, though half is too
good and ~1% would be closer. For instance, the reported case gives an error,
but:

real x
x = huge(1.0)
x = nearest(x,1.0)
end

which is equivalent to the first one, does not give any error even at -O1 and
above:

[karma] f90/bug% gfc -O -fno-range-check -fdump-tree-optimized
test_foverflow_1.f90
[karma] f90/bug% less test_foverflow_1.f90.116t.optimized

;; Function MAIN__ (MAIN__)

Analyzing Edge Insertions.
MAIN__ ()
{
  struct __st_parameter_dt dt_parm.1;
  static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
  real4 x;

<bb 2>:
  _gfortran_set_options (7, &options.0);
  x = 3.40282366920938463463374607431768211456e+38;
  dt_parm.1.common.filename = &"test_foverflow_1.f90"[1]{lb: 1 sz: 1};
  dt_parm.1.common.line = 3;
  dt_parm.1.common.flags = 128;
  dt_parm.1.common.unit = 6;
  _gfortran_st_write (&dt_parm.1);
  _gfortran_transfer_real (&dt_parm.1, &x, 4);
  _gfortran_st_write_done (&dt_parm.1);
  return;

}
[karma] f90/bug% gfc -O -fdump-tree-optimized test_foverflow.f90 <-- present
test
[karma] f90/bug% less test_foverflow.f90.116t.optimized

;; Function MAIN__ (MAIN__)

Analyzing Edge Insertions.
MAIN__ ()
{
  struct __st_parameter_dt dt_parm.1;
  static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
  real4 x;

<bb 2>:
  _gfortran_set_options (7, &options.0);
  x = _gfortran_nearest_r4 (3.4028234663852885981170418348451692544e+38,
1.0e+0);
  dt_parm.1.common.filename = &"test_foverflow.f90"[1]{lb: 1 sz: 1};
  dt_parm.1.common.line = 4;
  dt_parm.1.common.flags = 128;
  dt_parm.1.common.unit = 6;
  _gfortran_st_write (&dt_parm.1);
  _gfortran_transfer_real (&dt_parm.1, &x, 4);
  _gfortran_st_write_done (&dt_parm.1);
  return;

}

BTW is it normal that gfortran_nearest_r4 (3.4...4e+38, 1.0e+0) is not computed
at the optimized level in the second case, while it is done in the first one?
Is this a bug?

To end my "contribution" to this PR, I think a warning with both -std=f* and
-pedantic (thus an error with -pedantic-errors) is already an overkill, but
than an error by default is "user unfriendly" to say the least.


-- 


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

[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error

[kargl at gcc dot gnu dot org]

------- Comment #5 from kargl at gcc dot gnu dot org  2007-09-07 16:12 -------

If this is case 2
  real x
  x = huge(1.0)
  x = nearest(x,1.0)
  end

and this is case 1

  real x
  x = nearest(huge(1.0),1.0)
  end

then the answers are

> BTW is it normal that gfortran_nearest_r4 (3.4...4e+38, 1.0e+0) is not
> computed at the optimized level in the second case, while it is done
> in the first one?

Yes.

> Is this a bug?

No.


-- 


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

[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2007-09-11 08:47 -------
> If this is case 2 ... 

Yes

> then the answers are ...
> Yes.

Why? more precisely what are the rules behind this yes?


-- 


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

[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error

[fxcoudert at gcc dot gnu dot org]

------- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-09-11 09:55 -------
(In reply to comment #6)
> Why? more precisely what are the rules behind this yes?

Short answer: the statements are treated independently in the front-end.

When the front-end sees: "nearest(huge(1.0),1.0)", it parses the expression and
then tries to simplify it. huge(1.0) will be replaced by its value, and the
"nearest(xxxxxxx,1.0)" is simplified. (At that point, the front-end detects the
overflow and errors out.)

Normally, the inter-statement optimization is to be done by the middle-end. You
will find that the following code:

  x = 2.
  x = sqrt(x)

you will find that sqrt() is calculated at runtime for -O0, while the two
statements are simplified (and sqrt(2.) is precomputed at compile-time) at -O1.
For NEAREST, the middle-end doesn't perform the simplification because instead
of translating the Fortran statement into C99 functions directly, we use call
the libgfortran function gfortran_nearest_r4(), which the middle-end doesn't
know and can't optimized away. (Doing so is a missed optimization, now filed as
PR33387.)


-- 


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

[Bug fortran/33296] nearest(huge(1.0),1.0) gives an error

[dominiq at lps dot ens dot fr]

------- Comment #8 from dominiq at lps dot ens dot fr  2007-09-11 10:48 -------
Subject: Re:  nearest(huge(1.0),1.0) gives an error

> (Doing so is a missed optimization, now filed as PR33387.)

When fixed, will the second test throw an error or not?
While looking for jokes about Intel, I cannot resist this one:

>> Q:  What is the difference between here and infinity?
>> A:  Not all that much, really. It won't affect anybody anyway.


-- 


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

[Bug fortran/33296] [4.3/4.4 regression] nearest(huge(1.0),1.0) gives an error

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2008-02-19 15:59 -------
It seems things are now worse:

$ cat s.f90
real x
x = nearest(huge(1.0),1.0)
end
$ ./bin/gfortran s.f90
next.c:91:  assertion failed: !mpfr_set_exp ((x), (exp + 1))
f951: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

That's with MPFR 2.3.1 and GCC trunk rev. 132112 (a bit before 4.3 branching).


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|2007-09-04 12:34:17         |2008-02-19 15:59:33
               date|                            |
            Summary|nearest(huge(1.0),1.0) gives|[4.3/4.4 regression]
                   |an error                    |nearest(huge(1.0),1.0) gives
                   |                            |an error


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

[Bug fortran/33296] [4.3/4.4 regression] nearest(huge(1.0),1.0) gives an error

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2008-03-06 18:23 -------
> It seems things are now worse:
> next.c:91:  assertion failed: !mpfr_set_exp ((x), (exp + 1))
> f951: internal compiler error: Aborted

Works for me with 4.4.0 and 4.3.0 20080131/rev131976 and 4.3.0 (of today) on
x86_64.


-- 


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

[Bug fortran/33296] [4.3/4.4 regression] nearest(huge(1.0),1.0) gives an error

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2008-03-12 04:23 -------
I wlll look into this a bit.  This caught my attention because it says
ice-on-valid and it is set as an enhancement.  That makes no sense.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-02-19 15:59:33         |2008-03-12 04:23:15
               date|                            |


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

[Bug fortran/33296] [4.3/4.4 regression] nearest(huge(1.0),1.0) gives an error

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2008-03-12 04:43 -------
This works for me as well.  I think it has been fixed.  Dominique, can you
please confirm this is fixed for you? on 4.4


-- 


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

[Bug fortran/33296] [4.3/4.4 regression] nearest(huge(1.0),1.0) gives an error

[dominiq at lps dot ens dot fr]

------- Comment #13 from dominiq at lps dot ens dot fr  2008-03-12 08:04 -------
Subject: Re:  [4.3/4.4 regression] nearest(huge(1.0),1.0)
 gives an error

> Dominique, can you please confirm this is fixed for you?

Works for me too on 4.4 and 4.3.


-- 


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

[Bug fortran/33296] [4.3/4.4 regression] nearest(huge(1.0),1.0) gives an error

[jvdelisle at gcc dot gnu dot org]

------- Comment #14 from jvdelisle at gcc dot gnu dot org  2008-03-12 14:23 -------
I will put a test case in and close this.


-- 


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

[Bug fortran/33296] [4.3/4.4 regression] nearest(huge(1.0),1.0) gives an error

[jvdelisle at gcc dot gnu dot org]

------- Comment #15 from jvdelisle at gcc dot gnu dot org  2008-03-15 03:21 -------
Subject: Bug 33296

Author: jvdelisle
Date: Sat Mar 15 03:20:57 2008
New Revision: 133236

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133236
Log:
2008-03-14  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR testsuite/33296
        gfortran.dg/nearest_4.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/nearest_4.f90
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33296] [4.3/4.4 regression] nearest(huge(1.0),1.0) gives an error

[jvdelisle at gcc dot gnu dot org]

------- Comment #16 from jvdelisle at gcc dot gnu dot org  2008-03-15 03:23 -------
Closing, test case committed to avoid regression.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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