This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Bug Report (Float --> Integer Inplace Conversion Precision Pr oblem)
- To: Joe Murray <jmurray at dsrnet dot com>
- Subject: Re: Bug Report (Float --> Integer Inplace Conversion Precision Pr oblem)
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 08 May 2001 07:01:29 -0300
- Cc: David Welling <dwelling at dsrnet dot com>, gcc-bugs at gcc dot gnu dot org, j dot g dot casserly at worldnet dot att dot net
- Organization: GCC Team, Red Hat
- References: <01D3C2F94514D31187EB005004776D2025662D@ENG_TECH_SVR>
On May 8, 2001, Joe Murray <jmurray@dsrnet.com> wrote:
> I don't believe that it was claimed that this was an error.
It was filed as an internal compiler error (ice-on-legal-code). Looks
like an error to me :-)
> 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.
At the expense of a performance penalty. Floating-point numbers are
not always exact. In this particular case, you'd get the answer you
expect, but it may well be that a slightly different test case will
get the truncation just the same even with the extra rounding to 64 or
32 bits, so what's the gain?
> 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.
Sorry if my answer sounded harsh. It's just that this issue come up
every week or so, and I strongly disagree it's a problem in GCC.
People dealing with FP numbers should be educated about what they can
and cannot expect from them.
Perhaps we could generate the additional rounding instructions you
suggest when a given command-line option is given?
--
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