From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16658 invoked by alias); 2 Jan 2008 06:07:07 -0000 Received: (qmail 16580 invoked by uid 22791); 2 Jan 2008 06:07:06 -0000 X-Spam-Check-By: sourceware.org Received: from caip.rutgers.edu (HELO caip.rutgers.edu) (128.6.236.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jan 2008 06:06:33 +0000 Received: from caipclassic.rutgers.edu (caipclassic.rutgers.edu [128.6.237.54]) by caip.rutgers.edu (8.13.8/8.13.5) with ESMTP id m0266S43009045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Jan 2008 01:06:29 -0500 Date: Wed, 02 Jan 2008 06:07:00 -0000 From: "Kaveh R. GHAZI" To: Vincent Lefevre cc: gcc@gcc.gnu.org Subject: Re: MPFR 2.3.1 Release Candidate In-Reply-To: <20080101050817.GF6543@ay.vinc17.org> Message-ID: References: <20071229182306.GC6502@ay.vinc17.org> <20080101050817.GF6543@ay.vinc17.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-01/txt/msg00008.txt.bz2 On Tue, 1 Jan 2008, Vincent Lefevre wrote: > On 2007-12-31 14:38:21 -0500, Kaveh R. GHAZI wrote: > > The bug would need to be exposed using a mantissa size of a C type, like > > 53 for double, and the default exponent range. And all the global mpfr > > flags are cleared beforehand, > > Are they cleared before each call to MPFR functions? Yes I call mpfr_clear_flags() before each mpfr function call. Also, the individual mpfr types are initialized and destroyed for each call, no reuse occurs between different mpfr calls. However... > > I tried several things through gcc+mpfr-2.3.0 like asin(-0.0), but > > that folds to -0.0 correctly. > > Perhaps because the same variable is used for the input and output? Yes, reuse occurs for src and dest variable: mpfr_clear_flags (); inexact = func (m, m, GMP_RNDN); So I guess I got lucky here. :-) > > I tried a call to sqrt(2.0) with -frounding-math. But the inexact > > flag is apparently set and gcc appropriately does not fold this > > case, instead replying on the library call to get the rounding > > correct. > > The ternary value was correct, and I suppose that GCC tests the > ternary value instead of the global inexact flag (this is what one > does in general). Right, as seen above. Later on, I do check the global overflow and underflow flags, but not global inexact. > > Often the bug says it will fail on "huge" inputs, but doesn't say > > exactly what they are. > > Most of the time, testcases were included in the changesets (not > in 53 bits, but in general, this shouldn't matter). You may want > to look at them. I'll poke around some more and see if I can find something. --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu