From: Kbwms AT aol DOT com Message-ID: <79.182121c5.2c824b13@aol.com> Date: Sat, 30 Aug 2003 14:46:43 EDT Subject: Re: Arithmetic Exceptions in C99 To: djgpp-workers AT delorie DOT com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_79.182121c5.2c824b13_boundary" X-Mailer: 8.0 for Windows sub 6015 Reply-To: djgpp-workers AT delorie DOT com --part1_79.182121c5.2c824b13_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/30/2003 2:09:32 PM Eastern Standard Time, eliz AT elta DOT co DOT il writes: > >From: Kbwms AT aol DOT com > >Date: Sat, 30 Aug 2003 12:50:22 EDT > > > >Has anyone bothered to look at the source for libm.a to see what they do? > >I see expressions like (x-x)/(x-x) to produce a NaN and turn on the > >floating point invalid exception and "huge + x" (where huge =3D 1.0e30) > >to turn on the floating point inexact exception. In the log function > >is "-two54/zero" to turn on the floating point divide-by-zero exception > >and generate -infinity. > > All these tricks will trigger SIGFPE unless we force the x87 to > suppress exceptions. > That might be true but I have encountered no problems in my checkout of the long double functions. All out-of-bounds arguments have been tested without taking any precautions regarding the x87. From the info file for signal: `SIGFPE' The Floating Point Error signal. Generated in case of divide by zero exception (Int 00h), overflow exception (Int 04h), and any x87 co-processor exception, either generated by the CPU (Int 10h), or by the co-processor itself (Int 75h). The co-processor status word is printed by the default handler for this signal. *Note _status87::, for the definition of the individual bits of the status word. The DJGPP startup code masks all numeric exceptions, so this signal is usually only triggered by an integer divide by zero operation. If you want to unmask some of the numeric exceptions, see *Note _control87::. I gather from this that we have very little to be concerned about. KB Williams --part1_79.182121c5.2c824b13_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 8/30/2003 2:09:32 PM Eastern Standard= Time, eliz AT elta DOT co DOT il writes:

>From: Kbwms AT aol DOT com
>Date: Sat, 30 Aug 2003 12:50:22 EDT
>
>Has anyone bothered to look at the source for libm.a to see what they do= ?
>I see expressions like (x-x)/(x-x) to produce a NaN and turn on the
>floating point invalid exception and "huge + x" (where huge =3D3D 1.0e30= )
>to turn on the floating point inexact exception.  In the log functi= on
>is "-two54/zero" to turn on the floating point divide-by-zero exception<= BR> >and generate -infinity.

All these tricks will trigger SIGFPE unless we force the x87 to
suppress exceptions.


That might be true but I have encountered no problems in my checkout of the=20= long double functions.  All out-of-bounds arguments have been tested wi= thout taking any precautions regarding the x87. 

From the info file for signal:

`SIGFPE'
     The Floating Point Error signal.  Generated in= case of divide by
     zero exception (Int 00h), overflow exception (Int 0= 4h), and any x87
     co-processor exception, either generated by the CPU= (Int 10h), or
     by the co-processor itself (Int 75h).  The co-= processor status
     word is printed by the default handler for this sig= nal.  *Note
     _status87::, for the definition of the individual b= its of the
     status word.

     The DJGPP startup code masks all numeric exceptions= , so this
     signal is usually only triggered by an integer divi= de by zero
     operation.  If you want to unmask some of the=20= numeric exceptions,
     see *Note _control87::.


I gather from this that we have very little to be concerned about.


KB Williams --part1_79.182121c5.2c824b13_boundary--