Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <199905061509.KAA27980@modi.xraylith.wisc.edu>
X-Authentication-Warning: modi.xraylith.wisc.edu: localhost.xraylith.wisc.edu [127.0.0.1] didn't use HELO protocol
To: "Roger L Gates" <rgates AT chandlerevans DOT com>
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: EGCS bug when passing float NaN? 
In-reply-to: Your message of "Thu, 06 May 1999 10:22:31 EDT."
             <199905061426 DOT KAA28169 AT InterJet DOT chandlerevans DOT com> 
Date: Thu, 06 May 1999 10:09:03 -0500
From: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>

"Roger L Gates" <rgates AT chandlerevans DOT com> writes:
> The attached code gave different results than I expected
> using CYGWIN B20.1 (gcc --version == egcs-2.91.57):
> 
>   global: NaN = 7f99999a
>   passed: NaN = 7fd9999a
> 
> The bit pattern is different inside the subroutine!
> 
> I got similar results compiling with -mno-cygwin:
> 
>   global: 1.#QNAN0 = 7f99999a
>   passed: 1.#QNAN0 = 7fd9999a
[...]
>    (void) printf("global: %f = %lx\n", global.f, global.l);
>    (void) printf("passed: %f = %lx\n", passed.f, passed.l);
[...]

I don't believe this is a bug. The printf family of routines 
typically print out "NaN" when the format specified is float/double 
(most implementations compare the bit pattern to the NAN bit sequence 
or call isnan). When format is something else, it just prints the bit 
pattern directly.

I need to look up the IEEE fp docs for chapter and verse. Anybody
with a copy handy?

You may want to post this to one of the standards newsgroups and
see what folks say.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com