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 <ams AT ludd DOT ltu DOT se>
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
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

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:
>   <http://sourceware.org/ml/glibc-bugs/2007-06/msg00002.html>
> 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

- Raw text -