X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f From: Kbwms AT aol DOT com Message-ID: Date: Mon, 17 Nov 2003 17:05:27 EST Subject: Re: math_errhandling [PATCH] To: djgpp-workers AT delorie DOT com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_ea.41ceb297.2ceaa027_boundary" X-Mailer: 8.0 for Windows sub 6021 Reply-To: djgpp-workers AT delorie DOT com --part1_ea.41ceb297.2ceaa027_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Rich Dawe: In a message dated 11/17/2003 2:37:52 PM Eastern Standard Time, rich AT phekda DOT freeserve DOT co DOT uk writes: > >Keep in mind that the functions in libm suffer from no such restriction > >and raise exceptions whenever it seems appropriate. > > In the context of math_errhandling, "exception" means feraiseexcept, > fegetexcept, etc. That's why I put exception in quotes. > > I think you're talking about FP exceptions raised by the processor. Am I > correct? > That's true, but they are exactly the same exceptions nevertheless. Moreover, we have always had the ability to *set* floating point exceptions via _control87(), *test* them via _status87() and *clear* them via _clear87() or _fpreset() (which resets the FPU completely). The reason we have the functions in fenv.h is to satisfy the requirements of C99. At least that is the reason that I wrote them. I used the _*87() functions a lot when I was checking out the exception handlers. In the functions in libm.a you will often see that when a NaN is desired and the invalid operation exception is to be set a computation such as the following is performed: (x-x)/(x-x). Using one/(x-x) [one=1.0] yields an infinity and sets the division-by-zero floating point exception. In ef_pow.c you will find a statement like return s*huge*huge; where huge = 1.0e300 and s is nominally 1.0. This guarantees that the overflow floating point exception will be set and an infinity will be returned. KB Williams --part1_ea.41ceb297.2ceaa027_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Rich Dawe:

In a message dated 11/17/2003 2:37:52 PM Eastern Standard Time, rich AT phekda.= freeserve.co.uk writes:

>Keep in mind that the functions in libm suffer from no=20= such restriction
>and raise exceptions whenever it seems appropriate.

In the context of math_errhandling, "exception" means feraiseexcept,
fegetexcept, etc. That's why I put exception in quotes.

I think you're talking about FP exceptions raised by the processor. Am I
correct?


That's true, but they are exactly the same exceptions nevertheless.  Mo= reover, we have always had the ability to *set* floating point exceptions vi= a _control87(), *test* them via _status87() and *clear* them via _clear87()=20= or _fpreset() (which resets the FPU completely).  The reason we have th= e functions in fenv.h is to satisfy the requirements of C99.  At least=20= that is the reason that I wrote them.  I used the _*87() functions a lo= t when I was checking out the exception handlers.

In the functions in libm.a you will often see that when a NaN is desired and= the invalid operation exception is to be set a computation such as the foll= owing is performed: (x-x)/(x-x).  Using one/(x-x) [one=3D1.0] yields an= infinity and sets the division-by-zero floating point exception.  In e= f_pow.c you will find a statement like

return s*huge*huge;

where huge =3D 1.0e300 and s is nominally 1.0.

This guarantees that the overflow floating point exception will be set and a= n infinity will be returned.


KB Williams --part1_ea.41ceb297.2ceaa027_boundary--