Date: Sun, 19 Mar 2000 10:47:38 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Eric Rudd <rudd AT cyberoptics DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Unnormals???
In-Reply-To: <38D162B7.317C25BF@cyberoptics.com>
Message-ID: <Pine.SUN.3.91.1000319104643.13691D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Thu, 16 Mar 2000, Eric Rudd wrote:

> > > "sqrt(-1)" produces the invalid operation exception.
> 
> I believe this conforms to C99, as long as we document it.  However,
> in my sqrt implementation, I returned -QNaN and set errno

Are you sure?  My reading of the source and a small test program don't
support that assertion.

The source of sqrt.S defines NaN like this:

  NaN:
	.long	0xFFC00000

And then returns it like this:

  badarg:				/* x is definitely <0 or NaN */
	movl	$1, _errno
	flds	NaN
	ret

The bit pattern 0xFFC00000 is a single-precision QNaN with its sign
bit set, so when loaded with FLDS, it should cause the FPU to produce
our friend the real indefinite.  And that is exactly what I see inside
GDB if I step into `sqrt', stop right after the FLDS instruction and
type "info float"[1]:

  =>R7: Special 0xffffc00000000000 Real Indefinite (QNaN)

So it seems like we return the real indefinite in all the cases where
a function is documented to produce a NaN.  This is actually a Good
Thing IMHO, since it is consistent with what the FPU generates for
invalid operations.


[1] Some of you might not recognize the format of this output, because
it's coming from a snapshot of GDB 5.0, where the display produced by
"info float" was changed and made identical on all x86 targets.