Mail Archives: djgpp/2001/06/19/03:15:06
On Sat, 16 Jun 2001 23:25:58 +0300, "Eli Zaretskii"
<eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
>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.
I have managed to improve around the overflows.
>> 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?
Incidentally, why is there no isnan() function? It seems like a
natural thing to have.
>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. Maybe it was removed in a recent
version?
--
Bill Gates: "No computer will ever need more than 640K of RAM." -- 1980
"There's nobody getting rich writing software that I know of." -- 1980
"This antitrust thing will blow over." -- 1998
Combine neo, an underscore, and one thousand sixty-one to make my hotmail addy.
- Raw text -