From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27587 invoked by alias); 27 Jul 2007 21:43:51 -0000 Received: (qmail 27552 invoked by alias); 27 Jul 2007 21:43:40 -0000 Date: Fri, 27 Jul 2007 21:43:00 -0000 Message-ID: <20070727214340.27551.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libfortran/32841] [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dominiq at lps dot ens dot fr" 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-07/txt/msg02788.txt.bz2 ------- Comment #21 from dominiq at lps dot ens dot fr 2007-07-27 21:43 ------- Subject: Re: [4.3 regression] HUGE(1.0d0) output as +Infinity on ppc-darwin8 > Your idea on the order of #defines is probably on the right track. As I said, this is the quickest way to hide the problem. I have tested that it works and it's only the matter to know the equivalent of __CYGWIN__ for powerpc-darwin to implement it. Indeed it won't help to understand the origin of the problem which may resurface in an other context. It would help to have answers to the following questions: (1) why isfinite(DBL_MAX) is working, but not isfinite(HUGE(1.0d0))? Does libfortran convert HUGE(1.0d0) to long double? If not, what's happening? (2) Does configure use the system gcc or xgcc from the latest stage? In the first case, this explain why HAVE_BROKEN_ISFINITE is not defined, but raise the question of the relevance of building gcc through 3 stages while keeping the config at stage 1. I the second case, why HAVE_BROKEN_ISFINITE is not defined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841