[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