Date: Sat, 16 Jun 2001 23:25:58 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp AT delorie DOT com
Message-Id: <8361-Sat16Jun2001232557+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
In-reply-to: <3b2b7829.177292197@news.primus.ca> (invalid@erehwon.invalid)
Subject: Re: Mysterious NaNs...
References: <3b2b4290 DOT 163568911 AT news DOT primus DOT ca> <2561-Sat16Jun2001155617+0300-eliz AT is DOT elta DOT co DOT il> <3b2b5a7e DOT 169695543 AT news DOT primus DOT ca> <1190-Sat16Jun2001180202+0300-eliz AT is DOT elta DOT co DOT il> <3b2b7829 DOT 177292197 AT news DOT primus DOT ca>
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
Precedence: bulk

> From: invalid AT erehwon DOT invalid (Graaagh the Mighty)
> Newsgroups: comp.os.msdos.djgpp
> Date: Sat, 16 Jun 2001 15:18:53 GMT
> >
> >Do you really have NaNs in your computations, and if so, is there a
> >way to get rid of them?
> 
> They arise from some sort of overflow. It's easier just to let them
> accumulate and trap them.

I'd advise against that: how can you trust a numeric computation which
gives birth to NaNs out of thin air?  I suggest to find the reason for
these overflows.  You could selectively enable the numeric exceptions
by using `_control87', which might catch the overflowing code
red-handed.

> 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.

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.  At
least the compiler will not be able to play all its tricks with a
function call as it does with inline operations.