From owner-freebsd-bugs Tue Apr 11 16:50: 5 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 39ACC37B7C4 for ; Tue, 11 Apr 2000 16:50:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA53221; Tue, 11 Apr 2000 16:50:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 11 Apr 2000 16:50:03 -0700 (PDT) Message-Id: <200004112350.QAA53221@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Randall Hopper Subject: Re: i386/17914: float-to-double core dump on 3.4R Reply-To: Randall Hopper Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR i386/17914; it has been noted by GNATS. From: Randall Hopper To: Kevin Day , Bruce Evans , Thomas David Rivers Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: i386/17914: float-to-double core dump on 3.4R Date: Tue, 11 Apr 2000 19:42:02 -0400 Randall Hopper: |Ok, thanks for your clarification. That seems like very odd behavior to |wait until the "next" floating point instruction before signaling the |exception for the prior. That could potentially be pages away in the |instruction stream. Thomas David Rivers: |> Intuitively it seems like a bug (like waiting for a while before |> tripping a divide by zero fault). But I'll trust that you know more |> about the issues involved here than I do. | | It's how the fpu works in the x86 chip; an artifact of when the | FPU was a different chip. | | Some x86 compilers can be told to emit an extra instruction (kinda | like a dummy floating pt. instruction) so that any except can be | caught synchronously; but when you do this, it *really* slows down | floating point operations. Ok, thank you. That makes sense. I understand the behavior now. Randall. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message