Date: Tue, 19 Jun 2001 12:20:23 +0300 (IDT) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.)