Path: utzoo!attcan!ncrcan!hcr!david
From: david@hcr.uucp (David Fiander)
Newsgroups: comp.unix.i386
Subject: Re: Floating point emulator bug?
Keywords: 80387
Message-ID: <1990Jan12.132655.13949@hcr.uucp>
Date: 12 Jan 90 13:26:55 GMT
References: <1670@ctisbv.cti-software.nl>
Reply-To: david@zeus.UUCP (David Fiander)
Organization: HCR Corporation, Toronto
Lines: 36

In article <1670@ctisbv.cti-software.nl> pim@cti-software.nl (Pim Zandbergen)
writes:
>Consider the following program:
>
>main()
>{
>    double           a = 2147483648.0;
>    unsigned long    b;
>
>    b = (unsigned long) a;	/* core dump here */
>    printf("b = %lu\n", b);
>}
>
>Looks quite legal to me, but it will core dump with a floating
>point exception when compiled for Unix 386 and Xenix 386
>
>I have used gcc 1.36, ISC's pcc, and SCO Xenix 2.2.3 compilers.
>I have run the programs on ISC 386/ix 2.0.1 and SCO Xenix 386 2.3.1.
>The only working program was produced by the Xenix 286 compiler.
>It will also work on an AT&T 3B2 (with a Math Acceleration Unit)
>
>I suspect it is a bug in the floating point emulator. Maybe
>the 286 emulator does its own floating point emulation.

This is not a bug in the floating point emulation, it's a bug in the
code generators for all thoso compilers. This is the way
that the '387 really works.  There is a "good" reason for this
though.  When the 387 tries to convert a floating point variable to
an integer variable, if the float won't fit into the integer an
exception is generated.  The problem is that the '387 does not have
an unsigned integer type, and 2147483648 will not fit into a signed
32 bit integer.  The solution is to generate code to convert the
float into a 64 bit integer, and then throw away the top 32 bits (no
problem, eh?).

- David