Mail Archives: djgpp-workers/2003/11/17/17:06:13
--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
<HTML><FONT FACE=3Darial,helvetica><FONT SIZE=3D3 FAMILY=3D"SERIF" FACE=3D"=
Georgia" LANG=3D"0">Rich Dawe:<BR>
<BR>
In a message dated 11/17/2003 2:37:52 PM Eastern Standard Time, rich AT phekda.=
freeserve.co.uk 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">>Keep in mind that the functions in libm suffer from no=20=
such restriction<BR>
>and raise exceptions whenever it seems appropriate.<BR>
<BR>
In the context of math_errhandling, "exception" means feraiseexcept,<BR>
fegetexcept, etc. That's why I put exception in quotes.<BR>
<BR>
I think you're talking about FP exceptions raised by the processor. Am I<BR>
correct?<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'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.<BR>
<BR>
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 <BR>
<BR>
return s*huge*huge;<BR>
<BR>
where huge =3D 1.0e300 and s is nominally 1.0.<BR>
<BR>
This guarantees that the overflow floating point exception will be set and a=
n infinity will be returned.<BR>
<BR>
<BR>
KB Williams</FONT></HTML>
--part1_ea.41ceb297.2ceaa027_boundary--
- Raw text -