[Bug fortran/34230] New: Expressions of parameters evaluated with too high precision

[Bug fortran/34230] New: Expressions of parameters evaluated with too high precision

[burnus at gcc dot gnu dot org]

Found by FX. See
http://gcc.gnu.org/ml/fortran/2007-11/msg00208.html

 $ cat a.f90
   real, parameter :: y = exp(log(huge(y))+20)
   real, parameter :: x = log(y)
   print *, x, y
   end
 $ gfortran a.f90 -fno-range-check && ./a.out
    108.72284           +Infinity

The problem is the following: gfortran does not do:
  y = INF
  x = log(y) = log(INF) = INF
but it does:
  y = exp(log(huge())+20) = INF
  x = log(exp(log(huge())+20)) = log(huge())+20 = 108.7

Calculating with higher precision to obtain "y" is ok (though one gets
different results compared with the run-time evaluation, but I expect that the
differences are only minor. Having the correct precision from the beginning
would be also ok.)

However, I regard it as bug if for expressions using y not y but a variant with
higher precision.


-- 
           Summary: Expressions of parameters evaluated with too high
                    precision
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2007-11-26 00:12 -------
There is no bug here.  You have explicitly disabled
range checking.  This means that you no longer have
a limitation on range in constant folding.  It may
be help to look at -fdump-parse-tree.  YOu don't
have an Inf until you actually do the transfer.


-- 


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[terry at chem dot gu dot se]

------- Comment #2 from terry at chem dot gu dot se  2007-11-27 21:57 -------
(In reply to comment #1)
> There is no bug here.  You have explicitly disabled
> range checking.  This means that you no longer have
> a limitation on range in constant folding.  It may
> be help to look at -fdump-parse-tree.  YOu don't
> have an Inf until you actually do the transfer.
> 

In that case it's a wrong code bug.  With -fno-range-check you've told the
compiler to produce +Infinity rather than an overflow error.  Instead, it takes
it upon itself to produce something other than what the source says [which is
log(y), not log(some expression that may or may not be called y)].


-- 

terry at chem dot gu dot se changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |terry at chem dot gu dot se


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2007-11-27 22:45 -------
(In reply to comment #2)
> (In reply to comment #1)
> > There is no bug here.  You have explicitly disabled
> > range checking.  This means that you no longer have
> > a limitation on range in constant folding.  It may
> > be help to look at -fdump-parse-tree.  YOu don't
> > have an Inf until you actually do the transfer.
> > 
> 
> In that case it's a wrong code bug.

No!

> With -fno-range-check you've told the
> compiler to produce +Infinity rather than an overflow error.

No! No!

It does not say to produce a +Infinity.  It says to produce
whatever value fits into a floating point number with a
p-bit significand and exponential range of [-IMAX, IMAX]
where p depends on the type kind parameter and IMAX is either
INT_MAX or LONG_MAX.  The internal representation of a 
floating point constant is done with MPFR.


> Instead, it takes it upon itself to produce something other
> than what the source says [which is log(y), not log(some
> expression that may or may not be called y)].

No! No! No!

troutmask:kargl[205] cat a.f90
   real, parameter :: y = exp(log(huge(y))+20)
   real, parameter :: x = log(y)
   print *, x, y
   end

troutmask:kargl[206] gfc -fdump-parse-tree -fno-range-check a.f90

        symtree: y  Ambig 0
        symbol y (REAL 4)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC)
        value: 1.65093201e47

        symtree: x  Ambig 0
        symbol x (REAL 4)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC)
        value: 1.08722839e2


      WRITE UNIT=6 FMT=-1
        TRANSFER 1.08722839e2
        TRANSFER 1.65093201e47
      DT_END

Do you see +Infinity?

troutmask:kargl[209] cat a.f90
   real, parameter :: x = 1. / 0.
   print *, x
   end
troutmask:kargl[210] gfc -fdump-parse-tree -fno-range-check a.f90

        symtree: x  Ambig 0
        symbol x (REAL 4)(PARAMETER UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC)
        value: @Inf@


      WRITE UNIT=6 FMT=-1
        TRANSFER @Inf@
      DT_END

If one doesn't understand what a compiler option does, then it would
be prudent not to use that option.


-- 

kargl at gcc dot gnu dot org changed:

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


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[terry at chem dot gu dot se]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]



------- Comment #4 from terry at chem dot gu dot se  2007-11-27 22:56 -------
(In reply to comment #3)

(Admittedly from the 4.2.2 manual):
2.2 Options controlling Fortran dialect
-frange-check
    Enable range checking on results of simplification of constant expressions
during compilation. For example, by default, GNU Fortran will give an overflow
error at compile time when simplifying a = EXP(1000). With -fno-range-check, no
error will be given and the variable a will be assigned the value +Infinity.
Similarly, DATA i/Z'FFFFFFFF'/ will result in an integer overflow on most
systems, but with -fno-range-check the value will “wrap around” and i will be
initialized to -1 instead. 


That seems pretty explicit about what the option is supposed to be doing.

Referring to compiler output agreeing with itself is not a particularly strong
argument.

Surely it's reasonable for the programmer to assume that if y is +Inf, than
log(y) will be also.  (Though I can see this degenerating into a discussion
about -ffloat-store.)


-- 


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[kargl at gcc dot gnu dot org]

------- Comment #5 from kargl at gcc dot gnu dot org  2007-11-28 00:06 -------
(In reply to comment #4)
> (In reply to comment #3)
> 
> (Admittedly from the 4.2.2 manual):
> 2.2 Options controlling Fortran dialect
> -frange-check
>     Enable range checking on results of simplification of constant expressions
> during compilation. For example, by default, GNU Fortran will give an overflow
> error at compile time when simplifying a = EXP(1000). With -fno-range-check, no
> error will be given and the variable a will be assigned the value +Infinity.

The documentation is wrong.  Fortunately, I didn't write it.   I do 
commend you on actually trying to use the documentation.

> Referring to compiler output agreeing with itself is not a particularly strong
> argument.

I wrote or reworked most of the constant folding done in gfortran.  I think
I may be able to speak with some authority as to what the constant folding
is doing.  Showing the compiler's internal state in comment #3 was only
motivated by your comment #2, which appears to show that you don't understand
my comment #1.

> Surely it's reasonable for the programmer to assume that if y is +Inf, than
> log(y) will be also.

But, y is not +Inf.  

> (Though I can see this degenerating into a discussion about -ffloat-store.)

This absolutely nothing to do with -ffloat-store.  It has to do with
misleading documentation.  I'll submit a patch to fix that snafu.

I suspect that the only legal, but non-portable, method that allows
one to get an inf value in a variable is via TRANSFER().  


-- 


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-11-28 18:03 -------
I consider this a bug. I have to check, but I think that the IEEE rules are
clear, even though they are not mandatory until we introduce the corresponding
standard modules. The calculation of y does overflow, and while we can debate
on what the behaviour of -fno-range-check should be, I think there is a strong
case for doing the same thing that a) other compilers do, b) IEEE mandates, c)
is what would happen if it occurred at runtime.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[kargl at gcc dot gnu dot org]

------- Comment #7 from kargl at gcc dot gnu dot org  2007-11-28 19:06 -------
(In reply to comment #6)
> I consider this a bug. I have to check, but I think that the IEEE rules are
> clear, even though they are not mandatory until we introduce the corresponding
> standard modules. The calculation of y does overflow, and while we can debate
> on what the behaviour of -fno-range-check should be, I think there is a strong
> case for doing the same thing that a) other compilers do, b) IEEE mandates, c)
> is what would happen if it occurred at runtime.

a) Do other compilers have an equivalent to -fno-range-check?
b) The Fortran 95 standard is silent with respect to IEEE-754,
   and the Fortran 2003 standard only considers IEEE-754 through
   the explicit use of an intrinsic module.
c) Are you suggesting that -ffpe-trap=invalid,overflow,zero should be
   the default runtime behavior (to match gfortran's default 
   -frange-check behavior)?

If you want to be pedantic, this code is invalid

   real, parameter :: y = exp(log(huge(y))+20)

because (See 13.14)

   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 you're claiming +Inf is in the range of values representable by
a real (in which case, you can against remove range checking).  If +Inf
is a representable value, you need to go fix the IO subsystem to read
+Inf (and NaN).  

   character(len=60) str
   real inf, nan
   integer, parameter :: i = 2139095040, j = 2141192192
   inf = transfer(i,inf)  ! Legal, but non-portable
   nan = transfer(j,nan)  ! Legal, but non-portable
   write(str, *) inf, nan
   inf = 0
   nan = 0
   read(str, *) inf, nan
   print *, inf, nan
   end

troutmask:sgk[246] ./z
At line 9 of file a.f90
Fortran runtime error: Bad real number in item 1 of list input

You'll also need to fix modules to properly handle +Inf and NaN.

   module except
   real, parameter :: inf = 1./0., nan = 0./0.
   end module

   program a
     use except
     print *, inf, nan
   end program a

troutmask:sgk[251] gfc -o z -fno-range-check a.f90
troutmask:sgk[252] ./z
   0.000000       0.000000    


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|kargl at gcc dot gnu dot org|sgk at troutmask dot apl dot
                   |                            |washington dot edu


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[fxcoudert at gcc dot gnu dot org]

------- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-11-28 19:23 -------
(In reply to comment #7)
> a) Do other compilers have an equivalent to -fno-range-check?

Most compilers have a behaviour similar to -fno-range-check by default, only
warning about range problems (Intel, Sun, g95 and Portland). On the example of
this testcase, all report x and y as infinities.

> b) The Fortran 95 standard is silent with respect to IEEE-754,
>    and the Fortran 2003 standard only considers IEEE-754 through
>    the explicit use of an intrinsic module.

As I said: our current behaviour is standard-conforming, and -fno-range-check
is asking to drop some of the standard constraints. What we do then is outside
the scope of the standard, so we need to do something reasonable, and probably
follow a principle of least surprise.

> c) Are you suggesting that -ffpe-trap=invalid,overflow,zero should be
>    the default runtime behavior (to match gfortran's default 
>    -frange-check behavior)?

I am not, and don't see where I would imply such a thing. Trapping is widely
different: it means throwing a FPE signal on certain floating-point exceptions.

> If you want to be pedantic, this code is invalid
>    real, parameter :: y = exp(log(huge(y))+20)

I do agree. That's what -fno-range-check is about: compile invalid code in
cases where the community is not expecting bugs. In the end, I hope we win and
noone writes invalid code. For now... well, lots of people and existing codes
rely on such practice.

> unless you're claiming +Inf is in the range of values representable by
> a real

No, I'm not. That would be stretching a bit far!

> If +Inf is a representable value, you need to go fix the IO subsystem
> to read +Inf (and NaN).

Well, I happen to think that this would be a nice thing to do at some point.
That's an extension to the standard, of course, but that would be, IMHO, a
interesting one.

> You'll also need to fix modules to properly handle +Inf and NaN.

I wasn't aware of that one, but it is understandable. I think that it would
indeed be nice to change that behaviour.


To sum up my point of view: -fno-range-check is about accepting code which is,
strictly speaking, invalid. It is thus an extension and we should be guided by
a) what other compilers do, b) consistency, c) least surprise. Moreover, I
don't think changing that behaviour would hurt maintainability much (but I
might be wrong; we'll know when someone starts working on it).


-- 


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[burnus at gcc dot gnu dot org]

------- Comment #9 from burnus at gcc dot gnu dot org  2007-11-28 19:35 -------
> > If +Inf is a representable value, you need to go fix the IO subsystem
> > to read +Inf (and NaN).

I just checked:

- NAG f95, g95, ifort and sunf95 accept (case insensitive and with optional
"+"/"-" prefix) "NAN" and "INF", "Infinity". ("infini" is for instance
rejected.) 

- openf95, gfortran and g77 reject it.


-- 


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #10 from sgk at troutmask dot apl dot washington dot edu  2007-11-28 20:08 -------
Subject: Re:  Expressions of parameters evaluated with too high precision

On Wed, Nov 28, 2007 at 07:23:57PM -0000, fxcoudert at gcc dot gnu dot org
wrote:
> 
> To sum up my point of view: -fno-range-check is about accepting code which is,
> strictly speaking, invalid. It is thus an extension and we should be guided by
> a) what other compilers do, b) consistency, c) least surprise. Moreover, I
> don't think changing that behaviour would hurt maintainability much (but I
> might be wrong; we'll know when someone starts working on it).
> 

I have a patch that does what people seem to want.


-- 


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2007-11-30 04:11 -------
Subject: Bug 34230

Author: jvdelisle
Date: Fri Nov 30 04:10:47 2007
New Revision: 130530

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130530
Log:
2007-11-29  Steven G. Kargl  <kargls@comcast.net>

        PR fortran/34230
        * fortran/arith.c (gfc_check_real_range): Set intermediate values
        to +-Inf and 0 when -fno-range-check is in effect.
        * fortran/invoke.texi: Improve -fno-range-check description.

        PR fortran/34203
        * fortran/invoke.texi: Document the C escaped characters activated
        by -fbackslash.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/arith.c
    trunk/gcc/fortran/invoke.texi


-- 


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2007-11-30 04:18 -------
Subject: Bug 34230

Author: jvdelisle
Date: Fri Nov 30 04:18:05 2007
New Revision: 130532

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130532
Log:
2007-11-29  Steven G. Kargl  <kargls@comcast.net>

        PR fortran/34230
        * gfortran.dg/real_const_3.f90: Fix up for new range-check handling.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/gamma_5.f90
    trunk/gcc/testsuite/gfortran.dg/real_const_3.f90


-- 


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

[Bug fortran/34230] Expressions of parameters evaluated with too high precision

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2007-12-02 21:02 -------
Fixed on trunk. Hope everyone is satisfied.


-- 

jvdelisle at gcc dot gnu dot org changed:

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


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