Mail Archives: djgpp/2001/06/16/16:28:57
> 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.
- Raw text -