Bug Report (Float --> Integer Inplace Conversion Precision Problem)
Joe Murray
jmurray@dsrnet.com
Tue May 8 02:29:00 GMT 2001
Alexandre,
I don't believe that it was claimed that this was an error. This has been
identified as a problem, or better, inconsistent behavior. We have
identified this problem only on the x86 platform and found that all other
platforms that we have access to are self consistent. We have tested on x86,
PA-RISC, MIPS, PowerPC, and Sparc with a range of compilers.
Thanks to Geoff Keating (and others) of this list and several folks at
Intel. It is not often that we get to look at issues like this and provide
help back to the community. In fact, due in large part to the help and
prodding (and reprodding) of Geoff Keating we dug through the
gcc/config/i386/i386.c code to determine where the instructions are
generated. We provided this to Intel (and others) and they provided us with
assembly generated by their compiler. They demonstrated the issued regarding
carrying the extra precision without correction on assignment and cast.
Geoff and others suggested that we should look at the ANSI standard and we
found that GCC was behaving consistently with the standard but that there is
a "gray" area regarding the state of the floating point representation
before assignment. Intel showed us that their generated assembly forces data
from the FPU stack to the variable stack before the FISTPL instruction. This
corrects the value to the correct resolution.
This results in behavior that is self consistent between the intermediate
assignment to a float and the direct assignment to an integer. GCC behaves
this way on all other platforms that we have tested and we believe it should
on the x86.
We have provided a description of the problem, a repeatable example of the
problem, the assembly and and variable state information associated with the
problem, a description of the resolution, and a code patch for the
resolution. We are providing this to the GCC community for the common good.
If it is wrong please expand on specifically why it is wrong. We are trying
to contribute to a better more self consistent GCC compiler.
Sincerely,
Joe.
-----Original Message-----
From: Alexandre Oliva [ mailto:aoliva@redhat.com ]
Sent: Tuesday, May 08, 2001 2:48 AM
To: David Welling
Cc: gcc-bugs@gcc.gnu.org; jmurray@dsrnet.com;
j.g.casserly@worldnet.att.net
Subject: Re: Bug Report (Float --> Integer Inplace Conversion Precision
Problem)
On May 7, 2001, "David Welling" <dwelling@dsrnet.com> wrote:
> The inplace assignment should result in 7. It does not because the value
is
> copied straight from the FPU 80 bit register for the integer imm.
And why is this an error? Have you ever read ``What Every Computer
Scientist Should Know about Floating-Point Arithmetic''
http://www.validgh.com/goldberg/paper.ps ?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
More information about the Gcc-bugs
mailing list