From owner-freebsd-hackers  Fri Jul 18 09:57:14 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA02914
          for hackers-outgoing; Fri, 18 Jul 1997 09:57:14 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA02906
          for <hackers@FreeBSD.ORG>; Fri, 18 Jul 1997 09:57:11 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id CAA08954; Sat, 19 Jul 1997 02:52:36 +1000
Date: Sat, 19 Jul 1997 02:52:36 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199707181652.CAA08954@godzilla.zeta.org.au>
To: bdodson@beowulf.utmb.edu, hackers@FreeBSD.ORG
Subject: Re: PentiumPro/II floating point "errata" impact
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>Does anyone know if the floating point bug in PentiumPros and PentiumIIs
>is likely to be manifest in libm?  I'm talking about the unflagged
>overflow when converting from floating point to integer (FIST? or some 
>such).  If it is, does anyone know whether this can be handled by code 
>generation in the gcc backend?  (The Intel web site talks about software 
>workarounds.)

Overflow for this conversion gives undefined behaviour in ANSI C.
In FreeBSD, the default behaviour is to generate a SIGFPE.  If you mask
FPU exceptions, then FIST gives the result LONG_LONG_MIN for 64-bit
integers and sets various exception flags.  Gcc uses the 64-bit FIST
for both 32-bit and 64-bit integers and mangles it to various mostly
wrong values (except for calculations done at compile time, gcc acts
as if it used the 32-bit FIST and mangles it to different mostly wrong
values), e.g.,

	volatile double var = 1e50;

	(long)              1e50	= 	LONG_MIN		right
	(unsigned long)     1e50	=	0x80000000		wrong?
	(long)              var		= 	LONG_MIN		right
	(unsigned long)     var		=	0			wrong
	(long long)         1e50	= 	0xffffffff00000000	wrong
	(unsigned long long)1e50	=	0xffffffff00000000	wrong
	(long long)         var		= 	LONG_LONG_MIN		right
	(unsigned long long)var		=	0			wrong

Errors in setting the exception flags will probably be lost in this noise.

libm attempts to never generate overflows, except on purpose.  I think it
never generates a float -> int conversion overflow.

Bruce