From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23673 invoked by alias); 31 Dec 2007 19:39:48 -0000 Received: (qmail 23663 invoked by uid 22791); 31 Dec 2007 19:39:47 -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; Mon, 31 Dec 2007 19:38:45 +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 lBVJcL85004684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Dec 2007 14:38:32 -0500 Date: Mon, 31 Dec 2007 22:44: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: <20071229182306.GC6502@ay.vinc17.org> Message-ID: References: <20071229182306.GC6502@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: 2007-12/txt/msg00721.txt.bz2 On Sat, 29 Dec 2007, Vincent Lefevre wrote: > The release of MPFR 2.3.1 is imminent. Please help to make this > release as good as possible by downloading and testing this > release candidate: > [...] > Changes from version 2.3.0 to version 2.3.1: > - Bug fixes; see . > - Improved MPFR manual. Hi Vincent, I read through the bugs in 2.3.0 from the above link. I'm trying to see if I can write a GCC testcase that exposes one of those bugs when GCC is linked with mpfr-2.3.0, but passes when I use 2.3.1-rc1. 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, and the input precision is the same as the output precision. These circumstances seem to eliminate many (all?) of the potential failures. I tried several things through gcc+mpfr-2.3.0 like asin(-0.0), but that folds to -0.0 correctly. 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. I'd rather not test for inefficiencies or infinite loops because then the testcase will take too long to timeout and slow down everyone's testsuite runs. Often the bug says it will fail on "huge" inputs, but doesn't say exactly what they are. Rather than further guessing on my part, would you please suggest something? Thanks, --Kaveh -- Kaveh R. Ghazi ghazi@caip.rutgers.edu