Date: Thu, 20 Jun 2002 08:40:04 -0700 (PDT) From: "Andreas Haakh" <ah@Haakh.de> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/38170: fpgetmask, fpsetmask yield strange results Message-ID: <200206201540.g5KFe4007185@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: Thu, 20 Jun 2002 17:32:44 +0200 Hi, today I installed floatingpoint.h from HEAD and now the functions fp[sg]etmask yield the desired results. The reason, why I found the bug is, that somewhere in the past the default setting for npxcw was silently changed. Investigating the sources revealed, that http://www.freebsd.org/cgi/query-pr.cgi?pr=17984 changed the default floating point precision to 53 bits and masked _ALL_ exceptions in /sys/i386/include/npx.h! There was no note in UPDATING and this change caused quite some trouble. Since this PR we have #define __INITIAL_NPXCW__ 0x127F I think it would be better to have the initial value set to #define __INITIAL_NPXCW__ 0x1272 which would force a trap on FP_X_INV, FP_X_DZ and FP_X_OFL. This is a better behaviour for floatingpoint exceptions if you don't catch them at all and complies with the sample code in fpsetmask(3). This manpage should also describe the default settings. Whoever wants to prevent floating point exceptions should check and/or reset the sticky flags if needed and for those programs its not a big deal to set the exception mask to the desired value. The current setting silently ignores them and give strange (wrong!!!) results. If you don't agree to change the initial npxcw to my proposed value, it would be nice to have either a kernel configuration option or a sysctl-variable holding the initial npxcw for new processes.. Andreas ----- Original Message ----- From: "Andreas Haakh" <ah@haakh.de> To: "Bruce Evans" <bde@zeta.org.au> Cc: <FreeBSD-gnats-submit@FreeBSD.ORG> Sent: Wednesday, June 12, 2002 10:54 AM Subject: Re: kern/38170: fpgetmask, fpsetmask yield strange results > > ----- 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?200206201540.g5KFe4007185>