X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com From: Martin Str|mberg Message-Id: <200808011332.m71DWZTB019079@brother.ludd.ltu.se> Subject: Re: Retrun string for pseudo-nan and others. To: djgpp-workers AT delorie DOT com Date: Fri, 1 Aug 2008 15:32:35 +0200 (MEST) In-Reply-To: <200803161428.49368.juan.guerrero@gmx.de> from "Juan Manuel Guerrero" at Mar 16, 2008 02:28:48 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk According to Juan Manuel Guerrero: > > Modern configure scripts check what does printf return for Quiet NaN, > Signalling NaN, Pseudo-NaN, Pseudo-Infinity, Pseudo-Zero, Pseudo-Denormal > and denormalized numbers (unnormal). DJGPP's printf returns "Unnormal" > for all except for Quiet NaN and Signalling NaN making the test case fail. > According to: > > all of them shall return nan/NAN. The patch below will fix the issue and Not really relevant, see below. As the the behaviour is UB (IIRC) the error is in the configure scripts that makes bad assumptions. > make printf a little bit more glibc compatible. Neitherless this will > introduce backward compatibility problems because "Unnormal" is no longer > issued. ... > + /* > + * For intel's 80 bit floating point number identify > + * the following special values: > + * > + * Supported Floating-Point Encodings (generated by processor as an operation result) > + * exp mantissa high mantissa low > + * Quiet NaN: 0x7FFF, 11NNNNNNNNNNNNNNNNNNNNNNNNNNNNNN, NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN > + * Signalling NaN: 0x7FFF, 10NNNNNNNNNNNNNNNNNNNNNNNNNNNNNN, NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN > + * Infinity: 0x7FFF, 10000000000000000000000000000000, 00000000000000000000000000000000 > + * Pseudo-Denormal: 0x0000, 1NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN, NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN1 > + * > + * Unsupported Floating-Point Encodings (not generated by processor as an operation result) > + * exp mantissa high mantissa low > + * Pseudo-NaN: 0x7FFF, 0NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN, NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN1 > + * Pseudo-Infinity: 0x7FFF, 00000000000000000000000000000000, 00000000000000000000000000000000 > + * Pseudo-Zero: 0xNNN1, 00000000000000000000000000000000, 00000000000000000000000000000000 > + * Unnormal: 0xNNN1, 0NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN, NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN > + * > + * Patterns of the values according to: > + * Intel IA-64 Architecture Software Developer's Manual, Volume 1: > + * Application Architecture. > + * 5.1.3 "Representation of Values in Floating-Point Registers" > + * Table 5-2 "Floating-Point Register Encodings" > + * Figure 5-11 "Floating-Point Exception Fault Prioritization" > + * > + * To be compatible with printf of glibc Quiet NaN, signalling NaN, Pseudo-NaN, > + * Pseudo-Infinity, Pseudo-Zero, Pseudo-Denormal and denormalized numbers (unnormal) > + * shall all return nan/NAN. > + */ I'm just slightly confused: the web link and the comments talk about Intel IA-64, which equals Itanium not x86 (nor x86-64). Anyway, it doesn't matter much. You're doing the work. If it's ok with you and eases your porting, it ok. But the IA-64 comment is weird. -- MartinS