Date: Sat, 19 Jul 1997 02:52:36 +1000 From: Bruce Evans <bde@zeta.org.au> To: bdodson@beowulf.utmb.edu, hackers@FreeBSD.ORG Subject: Re: PentiumPro/II floating point "errata" impact Message-ID: <199707181652.CAA08954@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707181652.CAA08954>