Date: Wed, 12 Jun 2002 02:00:13 -0700 (PDT) From: "Andreas Haakh" <ah@haakh.de> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/38170: fpgetmask, fpsetmask yield strange results Message-ID: <200206120900.g5C90Dw74176@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/38170; it has been noted by GNATS.
From: "Andreas Haakh" <ah@haakh.de>
To: "Bruce Evans" <bde@zeta.org.au>
Cc: <FreeBSD-gnats-submit@FreeBSD.ORG>
Subject: Re: kern/38170: fpgetmask, fpsetmask yield strange results
Date: Wed, 12 Jun 2002 10:54:01 +0200
----- Original Message -----
From: "Bruce Evans" <bde@zeta.org.au>
To: "Andreas Haakh" <ah@alvman.Haakh.de>
Cc: <FreeBSD-gnats-submit@FreeBSD.ORG>
Sent: Saturday, June 01, 2002 7:54 PM
Subject: Re: kern/38170: fpgetmask, fpsetmask yield strange results
> On Fri, 17 May 2002, Andreas Haakh wrote:
>
> > >Description:
> > I tried to modify the default fp_exception-mask. The results from
fpgetmask and fpsetmask (and probably some other fp[sg]et-routines) are
buggy.
>
> fpsetmask() is fixed in -current. The complement of the mask (ANDed with
> the mask bitfield) was being returned. The other routines seem to be OK.
>
> > >How-To-Repeat:
> > The following codeexample shows this strange behaviour:
> >
> > #include <stdio.h>
> > #include <ieeefp.h>
> >
> > int main (void) {
> >
> > fp_except_t except, res;
> >
> > res=fpgetmask();
> >
> > printf ("fp_except from fpgetmask: \t0x%02x!\n", res);
> >
> > except = FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_STK;
>
> Note that FP_X_STK is output-only. Attempts to set it are ignored by
> fpsetmask(), and fpgetmask() returns whatever the hardware gives for
> attempts to set it in other initializations that don't mask it. It
> is documented as "reserved" in at least the i486 manual, so strictly
> it should not be set unconditionally, but the kernel just tries to
> write 0 to it. I wish that this bit controlled stack exceptions
> independently of invalid operand exceptions, so that SIGFPEs could
> be generated for the programming error of stack overflow without
> generating them for invalid operands which might not even be an error
> in programs that generate NaNs intentionally.
>
Is it already MFC'd or when will this happen?
There should be a note in fpsetask(3) that FP_X_STK is reserved...
Andreas
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206120900.g5C90Dw74176>