[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