Date: Thu, 13 Apr 2000 00:26:59 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: Randall Hopper <aa8vb@ipass.net>, stable@FreeBSD.ORG Subject: Re: float-to-double core dump on 3.4R Message-ID: <200004130727.e3D7RWh02100@cwsys.cwsent.com> In-Reply-To: Your message of "Thu, 13 Apr 2000 13:35:26 %2B1000." <00Apr13.133526est.115284@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <00Apr13.133526est.115284@border.alcanet.com.au>, Peter
Jeremy write
s:
> On 2000-Apr-09 10:02:46 +1000, Randall Hopper <aa8vb@ipass.net> wrote:
> > #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).
>
> Exactly what version of -stable are you running? If you built your
> own kernel, what version is /sys/i386/include/npx.h?
>
> The FP handling changed just before 4.0-RELEASE.
3.4 with npx.h from the 4.0 tree doesn't core dump. It's obviously the
fix to this problem and the Acroread4 floating point core. Thanks to
"Sean O'Connell" <sean@stat.Duke.EDU> for sending me the fix.
Here's the fix, from 4.0, that Sean sent me.
--- npx.h.releng_3 Wed Apr 12 16:28:38 2000
+++ npx.h Wed Apr 12 16:33:36 2000
@@ -85,54 +85,24 @@
u_char sv_pad[64]; /* padding; used by emulators */
};
-/* Intel prefers long real (53 bit) precision */
-#define __iBCS_NPXCW__ 0x262
-/* wfj prefers temporary real (64 bit) precision */
-#define __386BSD_NPXCW__ 0x362
/*
- * bde prefers 53 bit precision and all exceptions masked.
- *
- * The standard control word from finit is 0x37F, giving:
+ * The hardware default control word for i387's and later coprocessors
is
+ * 0x37F, giving:
*
* round to nearest
* 64-bit precision
* all exceptions masked.
*
- * Now I want:
+ * We modify the affine mode bit and precision bits in this to give:
*
* affine mode for 287's (if they work at all) (1 in bitfield 1<<12)
* 53-bit precision (2 in bitfield 3<<8)
- * overflow exception unmasked (0 in bitfield 1<<3)
- * zero divide exception unmasked (0 in bitfield 1<<2)
- * invalid-operand exception unmasked (0 in bitfield 1<<0).
*
* 64-bit precision often gives bad results with high level languages
* because it makes the results of calculations depend on whether
* intermediate values are stored in memory or in FPU registers.
- *
- * The "Intel" and wfj control words have:
- *
- * underflow exception unmasked (0 in bitfield 1<<4)
- *
- * but that causes an unexpected exception in the test program
'paranoia'
- * and makes denormals useless (DBL_MIN / 2 underflows). It doesn't
make
- * a lot of sense to trap underflow without trapping denormals.
- *
- * Later I will want the IEEE default of all exceptions masked. See
the
- * 0.0 math manpage for why this is better. The 0.1 math manpage is
empty.
*/
-#define __BDE_NPXCW__ 0x1272
-#define __BETTER_BDE_NPXCW__ 0x127f
-
-#ifdef __BROKEN_NPXCW__
-#ifdef __FreeBSD__
-#define __INITIAL_NPXCW__ __386BSD_NPXCW__
-#else
-#define __INITIAL_NPXCW__ __iBCS_NPXCW__
-#endif
-#else
-#define __INITIAL_NPXCW__ __BDE_NPXCW__
-#endif
+#define __INITIAL_NPXCW__ 0x127F
#ifdef KERNEL
extern struct proc *npxproc;
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004130727.e3D7RWh02100>