Date:	Tue, 19 Jun 2001 12:20:23 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: Mysterious NaNs...
In-Reply-To:	<3b2ef9f1.318958@news.primus.ca>
Message-ID:	<Pine.SUN.3.91.1010619121629.7390Y-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 19 Jun 2001, Graaagh the Mighty wrote:

> >> Regardless of all of this, the fundamental problem stays unaddressed:
> >> a sequence of instructions is being misplaced by the optimizer.
> >
> >Not really.  The optimizer is allowed to do any transformations that
> >don't change the outcome of a program.  Since operations on NaNs are
> >arithmetic nonsense, and your tests look like something that should
> >never happen (like a*a < 0), the optimizer might decide that some
> >parts of your program are dead code, and optimize them out of
> >existence.  GCC 2.95.x is known to be very aggressive in its
> >optimizations.
> 
> Enough to actually recognize a test for something's square against
> zero?

It's possible.  GCC is known to do very complicated and weird stuff when 
NaNs are involved.

> >If you insist on leaving NaNs instead of finding the reason for their
> >being there, your best bet would be to use the library function
> >`isnan' and maybe also `isinf' (link with -lm) for these tests.
> 
> Except that there is no such function. I could have sworn there was,
> but when I went to check on what headers and syntax to use with "info
> libc a isnan" I got a rude surprise.

Didn't you see that I said (above) ``link with -lm''?  Functions from 
libm.a re documented in a separate Info file.  Try "info libm", and you 
will find the docs of `isnan'.  (Assuming you have DJGPP v2.02 or later 
installed.)

- Raw text -