Date: Tue, 11 Apr 2000 16:20:03 -0700 (PDT) From: Randall Hopper <aa8vb@ipass.net> To: freebsd-bugs@FreeBSD.org Subject: Re: i386/17914: float-to-double core dump on 3.4R Message-ID: <200004112320.QAA50708@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/17914; it has been noted by GNATS.
From: Randall Hopper <aa8vb@ipass.net>
To: Kevin Day <toasty@dragondata.com>, Bruce Evans <bde@zeta.org.au>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004112320.QAA50708>