From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13354 invoked by alias); 28 Nov 2007 00:06:38 -0000 Received: (qmail 13314 invoked by uid 48); 28 Nov 2007 00:06:27 -0000 Date: Wed, 28 Nov 2007 00:06:00 -0000 Message-ID: <20071128000627.13313.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: "kargl 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/msg02719.txt.bz2 ------- 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