Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Apr 2000 21:40:04 -0700 (PDT)
From:      Bruce Evans <bde@zeta.org.au>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: i386/17914: float-to-double core dump on 3.4R
Message-ID:  <200004110440.VAA48579@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: Bruce Evans <bde@zeta.org.au>
To: aa8vb@ipass.net
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: i386/17914: float-to-double core dump on 3.4R
Date: Tue, 11 Apr 2000 14:39:21 +1000 (EST)

 On Mon, 10 Apr 2000 aa8vb@ipass.net wrote:
 
 > >Description:
 > 
 > 	     #include <float.h>
 > 	
 > 	     main()
 > 	     {
 > 	        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").
 
 Bruce
 
 


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?200004110440.VAA48579>