From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6675 invoked by alias); 28 Oct 2006 13:29:11 -0000 Received: (qmail 6593 invoked by uid 48); 28 Oct 2006 13:28:56 -0000 Date: Sat, 28 Oct 2006 13:29:00 -0000 Message-ID: <20061028132856.6592.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ghazi at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-10/txt/msg02393.txt.bz2 List-Id: ------- Comment #19 from ghazi at gcc dot gnu dot org 2006-10-28 13:28 ------- (In reply to comment #18) > (In reply to comment #17) > > Yes, I can reproduce the NaN. In fact, any negative value > > gives a NaN. > Not any negative value, but in lngamma.c: > /* if x < 0 and -2k-1 <= x <= -2k, then lngamma(x) = NaN */ > probably because the gamma value is negative. This is because MPFR defines > lngamma as log(gamma(x)) while the C standard defines it as log|gamma(x)|. I > wonder if this should be regarded as a bug or if a new function (say, > mpfr_lgamma) should be defined in MPFR (in which case, not before 2.3.0). The documenation in MPFR says: -- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND) Set ROP to the value of the Gamma function on OP, and its logarithm respectively, rounded in the direction RND. When OP is a negative integer, NaN is returned. It only talked about negative integers, and I glossed over the fact that it left out the absolute value that C does. So it was pilot error, but I think a clarification would help. Many times in the docs MPFR takes pains to follow the C99 standard, e.g. the inputs to atan2 or pow. Where you deviate from it should also be noted. Or you could consider it a bug and fix it. :-) Anyway, I think I can hand wrap mpfr_log(mpfr_abs(mpfr_gamma)) myself right? > Also, warning! The mpfr_erfc is incomplete for x >= 4096: There is an infinite > loop in the 2.2 branch. This problem is now detected in the trunk, and until > this is completely fixed, a NaN is returned with the MPFR erange flag set. This > should be in the 2.2 branch in a few days (and a preversion of MPFR 2.2.1 will > come several days after that). If it returns NaN for now that's fine since GCC avoids any transformation that returns NaN or Inf. Glad to hear a new version is coming out. If you make a prerelease tarball available somewhere I'd like to try it with mainline GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335