Mail Archives: djgpp-workers/2003/08/30/14:47:09
--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
<HTML><FONT FACE=3Darial,helvetica><FONT SIZE=3D3 FAMILY=3D"SERIF" FACE=3D"=
Georgia" LANG=3D"0">In a message dated 8/30/2003 2:09:32 PM Eastern Standard=
Time, eliz AT elta DOT co DOT il writes:<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT><FONT COLOR=3D"#000000"=
style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 FAMILY=3D"SANSSERIF" FACE=3D"A=
rial" LANG=3D"0">>From: Kbwms AT aol DOT com<BR>
>Date: Sat, 30 Aug 2003 12:50:22 EDT<BR>
><BR>
>Has anyone bothered to look at the source for libm.a to see what they do=
?<BR>
>I see expressions like (x-x)/(x-x) to produce a NaN and turn on the<BR>
>floating point invalid exception and "huge + x" (where huge =3D3D 1.0e30=
)<BR>
>to turn on the floating point inexact exception. In the log functi=
on <BR>
>is "-two54/zero" to turn on the floating point divide-by-zero exception<=
BR>
>and generate -infinity.<BR>
<BR>
All these tricks will trigger SIGFPE unless we force the x87 to<BR>
suppress exceptions.<BR>
</BLOCKQUOTE><BR>
</FONT><FONT COLOR=3D"#000000" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D3=
FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><BR>
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. <BR>
<BR>
From the info file for signal:<BR>
<BR>
`SIGFPE'<BR>
The Floating Point Error signal. Generated in=
case of divide by<BR>
zero exception (Int 00h), overflow exception (Int 0=
4h), and any x87<BR>
co-processor exception, either generated by the CPU=
(Int 10h), or<BR>
by the co-processor itself (Int 75h). The co-=
processor status<BR>
word is printed by the default handler for this sig=
nal. *Note<BR>
_status87::, for the definition of the individual b=
its of the<BR>
status word.<BR>
<BR>
The DJGPP startup code masks all numeric exceptions=
, so this<BR>
signal is usually only triggered by an integer divi=
de by zero<BR>
operation. If you want to unmask some of the=20=
numeric exceptions,<BR>
see *Note _control87::.<BR>
<BR>
<BR>
I gather from this that we have very little to be concerned about.<BR>
<BR>
<BR>
KB Williams</FONT></HTML>
--part1_79.182121c5.2c824b13_boundary--
- Raw text -