From owner-freebsd-current Tue Aug 25 06:21:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA25978 for freebsd-current-outgoing; Tue, 25 Aug 1998 06:21:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA25971 for ; Tue, 25 Aug 1998 06:21:16 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id JAA23287; Tue, 25 Aug 1998 09:20:29 -0400 (EDT) (envelope-from luoqi) Date: Tue, 25 Aug 1998 09:20:29 -0400 (EDT) From: Luoqi Chen Message-Id: <199808251320.JAA23287@lor.watermarkgroup.com> To: current@FreeBSD.ORG, shocking@prth.pgs.com Subject: Re: Floating Point Exceptions, signal handlers & subsequent ops Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I've noticed in one of my applications that the first FP operation after > return from a caught SIGFPE is invalid. I have a signal handler installed that > just prints out some basic info (like "SIGFPE caught"). The first FP op after > this (in my case, converting a long to a double) just gives garbage. Repeat > the same statement and it gives a sensible result. Has anyone else seen this > before I file a PR with code to reproduce the problem? > > > Stephen > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California > > Your SIGFPE handler has to restore the FP register stack top, and this is no easy job to do, you have to handle each exception type differently. It's not FreeBSD's problem, rather a stupid design on intel's part. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message