From rhh@rr.com  Mon Apr 10 17:49:38 2000
Return-Path: <rhh@rr.com>
Received: from rr.com (rdu25-22-143.nc.rr.com [24.25.22.143])
	by hub.freebsd.org (Postfix) with ESMTP id 4179C37B541
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 10 Apr 2000 17:49:35 -0700 (PDT)
	(envelope-from rhh@rr.com)
Received: (from rhh@localhost)
	by rr.com (8.9.3/8.9.3) id UAA13808;
	Mon, 10 Apr 2000 20:48:48 -0400 (EDT)
	(envelope-from rhh)
Message-Id: <200004110048.UAA13808@rr.com>
Date: Mon, 10 Apr 2000 20:48:48 -0400 (EDT)
From: aa8vb@ipass.net
Sender: rhh@rr.com
Reply-To: aa8vb@ipass.net
To: FreeBSD-gnats-submit@freebsd.org
Cc: aa8vb@ipass.net
Subject: float-to-double core dump on 3.4R
X-Send-Pr-Version: 3.2

>Number:         17914
>Category:       i386
>Synopsis:       float-to-double core dump on 3.4R
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 10 17:50:00 PDT 2000
>Closed-Date:    Tue Apr 11 06:04:16 PDT 2000
>Last-Modified:  Tue Apr 11 16:50:01 PDT 2000
>Originator:     Randall Hopper
>Release:        FreeBSD 3.4-RELEASE i386
>Organization:
self
>Environment:

	Stock 3.4-RELEASE (gcc 2.7.2.3 as shipped)

>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).

	Note that the core dump does not occur when the Inf is generated,
        but only when it is promoted to a double.

        I first noticed this by trying to printf the value of f after f=f*2
	and got the same core-dump behavior (due to float-to-double arg
	promotion).
	
>How-To-Repeat:

	Paste the above snippet into a .c file, compile with cc -o tst
	tst.c, and execute.

>Fix:
	
	Unknown.


>Release-Note:
>Audit-Trail:

From: Kevin Day <toasty@dragondata.com>
To: aa8vb@ipass.net
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: i386/17914: float-to-double core dump on 3.4R
Date: Mon, 10 Apr 2000 22:47:51 -0500 (CDT)

 > 	     #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).
 > 
 > 	Note that the core dump does not occur when the Inf is generated,
 >         but only when it is promoted to a double.
 > 
 >         I first noticed this by trying to printf the value of f after f=f*2
 > 	and got the same core-dump behavior (due to float-to-double arg
 > 	promotion).
 
 
 See 'man setfpmask'. The default behavior in 3.4 was to cause a SIGFPE if
 you do anything that causes an 'overflow' to be generated from the FPU. I
 admit this is weird that it's doing it here, but I don't claim to understand
 what happens in a case like this. :)
 
 (4.0 and higher changed their defaults to ignore certain exceptions)
 
 
 Kevin
 

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
 
 
State-Changed-From-To: open->closed 
State-Changed-By: sheldonh 
State-Changed-When: Tue Apr 11 06:04:16 PDT 2000 
State-Changed-Why:  
Asked and answered. 

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
 

From: Randall Hopper <aa8vb@ipass.net>
To: Kevin Day <toasty@dragondata.com>, Bruce Evans <bde@zeta.org.au>,
	Thomas David Rivers <rivers@dignus.com>
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.
 
>Unformatted:
