From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12744 invoked by alias); 27 Feb 2007 22:04:13 -0000 Received: (qmail 12700 invoked by uid 48); 27 Feb 2007 22:04:02 -0000 Date: Tue, 27 Feb 2007 22:04:00 -0000 Message-ID: <20070227220402.12699.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/30981] a ** exp fails for integer exponents if exp is "-huge()-1" (endless loop) In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus 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-02/txt/msg02996.txt.bz2 ------- Comment #8 from burnus at gcc dot gnu dot org 2007-02-27 22:04 ------- > > Also isn't -huge()-1 undefined code for Fortran? > -huge()-1 can be defined in Fortran. [...] > I'll also note that -pedantic will reject -huge()-1 Just for completeness: In the original example (the very long, incomplete F77 code) the problem was due to an overflow of: integer :: exponent ! temp very large or +INF exponent = log10(temp) Thus as long as such -huge()-1 and (for floating point numbers) INF, NAN and denormal numbers exists, the intrinsics have to deal with it somehow. (In reply to comment #4) > > With example I mean something which actually compiles and runs. Here, I have > > two problems: > > include '$(where)/amos/include/essential.ecm' > > is missing as well as the main program which calls the routine. > > I really try to do this, but I am an "old" fortran programer and > I do not know how to set +Infinity. Yes, of course, I have a case > that computes it and then hangs, but my code is over 500,000 lines > long and I did not think it is appropriate. Well, given that you have 500,000+ lines, it was already quite short and I was able to reproduce the problem even without the essential.ecm file. (Actually, reproducing was easier than I initially feared.) In any case: Thanks for reporting this bug. [Comparison with 10.0] > This is not as silly as it sounds. All I care about is to handle > the special case of 10 (exactly). I have seen cases where the > equality fails, but the number is really 10. I'm sure that the two numbers are then not exactly the same (bitwise) though; nonetheless I'm not good at predicting when an operation will cause an off-by-one (bit) and when not. I also failed to cook up a small example for 10.0 To create infinity etc. one can simply do: real :: zero, r zero = 0.0 r = 1.0/zero ! => +INF r = zero/zero ! => NaN r = -1.0/zero ! => -INF -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981