From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17923 invoked by alias); 28 Nov 2007 19:24:08 -0000 Received: (qmail 17834 invoked by uid 48); 28 Nov 2007 19:23:57 -0000 Date: Wed, 28 Nov 2007 19:24:00 -0000 Message-ID: <20071128192357.17833.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/34230] Expressions of parameters evaluated with too high precision In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "fxcoudert at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg02819.txt.bz2 ------- 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