From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-24181-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9677 invoked by alias); 8 Nov 2002 06:06:01 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 9663 invoked by uid 71); 8 Nov 2002 06:06:01 -0000
Date: Thu, 07 Nov 2002 22:06:00 -0000
Message-ID: <20021108060601.9662.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Tim Prince <tprince@computer.org>
Subject: Re: other/8484: gcc 3.2: log(0) => NaN ; -(Inf) => NaN; should return -Inf
Reply-To: Tim Prince <tprince@computer.org>
X-SW-Source: 2002-11/txt/msg00395.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR other/8484; it has been noted by GNATS.

From: Tim Prince <tprince@computer.org>
To: kabal@ECE.McGill.CA, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: other/8484: gcc 3.2: log(0) => NaN ; -(Inf) => NaN; should return -Inf
Date: Thu, 7 Nov 2002 22:04:24 -0800

 On Wednesday 06 November 2002 13:01, kabal@ECE.McGill.CA wrote:
 > >Number:         8484
 > >Category:       other
 > >Synopsis:       gcc 3.2: log(0) => NaN ; -(Inf) => NaN; should return -Inf
 
 > >Originator:     Peter Kabal
 > >Release:        gcc version 3.2 20020818 (prerelease)
 > >Organization:
 > >Environment:
 >
 > Cygwin under Windows XP pro
 >
 > >Description:
 >
 > Tests show that log(0) returns NaN and negating Inf also gives NaN. Under
 > previous 2.9x versions of gcc, these would both return -Inf.
 >
 
 > #include <math.h>
 >
 > int main (int argc, const char *argv[])
 >
 > {
 >   double dv;
 >
 >   dv = -sqrt(1.0) / 0.0;
 >   printf ("-sqrt(1) = %g\n", dv);
 >   dv = log (0.0);
 >   printf ("log(0) = %g\n", dv);
 >
 >   return 0;
 > }
 I find it difficult to believe that the gcc version you use is 
 directly responsible for the behavior of newlib printf(), if that's what you 
 are claiming.  gcc-3.3 with an old glibc on linux is giving me your expected 
 result; gcc-3.3 on cygwin with the standard newlib is behaving as you report. 
 Neither glibc nor newlib is under the influence of gcc maintainers.  I doubt 
 you will find a gcc maintainer willing to install the various gcc versions on 
 cygwin, to see if they do in fact alter the behavior of newlib, nor do I see 
 what you expect gcc to do about newlib.
 -- 
 Tim Prince