From owner-freebsd-bugs Wed Jun 12 2: 0:24 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 6DBBA37B40D for ; Wed, 12 Jun 2002 02:00:13 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g5C90Dw74176; Wed, 12 Jun 2002 02:00:13 -0700 (PDT) (envelope-from gnats) Date: Wed, 12 Jun 2002 02:00:13 -0700 (PDT) Message-Id: <200206120900.g5C90Dw74176@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Andreas Haakh" Subject: Re: kern/38170: fpgetmask, fpsetmask yield strange results Reply-To: "Andreas Haakh" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/38170; it has been noted by GNATS. From: "Andreas Haakh" To: "Bruce Evans" Cc: Subject: Re: kern/38170: fpgetmask, fpsetmask yield strange results Date: Wed, 12 Jun 2002 10:54:01 +0200 ----- Original Message ----- From: "Bruce Evans" To: "Andreas Haakh" Cc: 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 > > #include > > > > 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