From owner-freebsd-bugs Tue Apr 11 16:20: 6 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 0FF6937BB06 for ; Tue, 11 Apr 2000 16:20:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA50708; Tue, 11 Apr 2000 16:20:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Tue, 11 Apr 2000 16:20:03 -0700 (PDT) Message-Id: <200004112320.QAA50708@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 Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: i386/17914: float-to-double core dump on 3.4R Date: Tue, 11 Apr 2000 19:06:52 -0400 Bruce Evans: |> float f = FLT_MAX; |> double d; |> f = f * 2; |> d = f; |> |> Delete the "d=f" line and it doesn't core. Put it in and it does |> (floating-point exception). |> |> From this it appears there may be a bug in the float-to-double |> promotion when f is Inf (or, at least I'd expect that f is Inf). | |No. "f * 2" gives undefined behaviour since it overflows. For FreeBSD-3.4 |on i386's, the actual behaviour is to leave the operands on the FP stack |and cause a SIGFPE on the next FP instruction after the one that overflowed. | |> Note that the core dump does not occur when the Inf is generated, |> but only when it is promoted to a double. | |Inf is not generated. The operands are left on the FP stack for the SIGFPE |handler to fix up. This behaviour is easy to see using gdb ("display/i $pc", |"stepi" and "info float"). 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. 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. Thanks for the reply, Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message