RE: Bug Report (Float --> Integer Inplace Conversion Precision Pr oblem)

[Joe Murray <jmurray at dsrnet dot com>]

Alexandre,

I agree that a flag may well be the best approach. I would think that with
this coming up this often a flag is appropriate.

We have made a change to a local copy of GCC 2.95 and committed it to an
internal CVS repository. We have already had many requests for the patched
version. My feeling is that if many people want it than that says something
about the need. 

We have several million lines of code that we are deploying on Linux boxes
and it is really hard to find every possible location of this problem. Often
a simple test case results in an error. For example:

if ((int) pow(2.0,(double)((int)(log((double)fft_size)/log(2.0)))) !=
fft_size ){
	err_handle(FFT_SIZE);
}

If fft_size = 8192 the test results in 4096 under GCC on x86 and then calls
an error handler. This simple test just checks that the FFT size is actually
on a power 2 boundry.

There certainly is a performance issue and that is why I would recommend a
flag too. Some folks are not going to have a bunch of legacy code to deal
with and they can be careful to avoid these traps. Others will need the
flag.

Thanks,

Joe.

-----Original Message-----
From: Alexandre Oliva [mailto:aoliva@redhat.com]
Sent: Tuesday, May 08, 2001 6:01 AM
To: Joe Murray
Cc: David Welling; gcc-bugs@gcc.gnu.org; j.g.casserly@worldnet.att.net
Subject: Re: Bug Report (Float --> Integer Inplace Conversion Precision
Pr oblem)


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