Floating point computation "non-bug"

[Dave Elcock <dave at sias dot com>]

Hi.

I've recently installed Mandrake 9.1 which comes with GCC 3.2.2. One of 
the first things I checked with the new compiler suite was the old 
floating point problems I used to get, hoping they would be somehow 
magically resolved. Well, the old problems are still there.

"Yeah, here we go again", I hear you say. Please keep reading. Here's a 
ridiculously simple example of what's going wrong for me:


#include <stdio.h>
#include <stdlib.h>

int main (int argc,char **argv)
{
	float f1, f2;
	f1 = atof(argv[1]);
	f2 = f1 * 10.0;
	printf("f1              %f\n"
	       "f2              %f\n"
	       "(int)f2         %d\n"
	       "(int)(f1*10.0)  %d\n",
	       f1, f2, (int)f2, (int)(f1*10.0));
}


Simply compiling with 'gcc test.c' and then running './a.out 2.3' gives 
the following output:

f1              2.300000
f2              23.000000
(int)f2         23
(int)(f1*10.0)  22


I can't see how such a simple example should be affected by floating 
point precision. At the very least, the last two answers should be 
consistent. I would suggest that this IS a bug, despite the text of the 
explanation on the GCC Bugs web page, and the linked paper.

Compiled with another compiler (e.g. Portland Group's pgcc), I get the 
correct answer for the last line, so it's not about the machine's precision.

If I had the expertise necessary to help with this, you could be sure 
I'd get stuck right in and help out.

This is a serious and very frustrating flaw in an otherwise superb 
compiler suite. Why does the problem keep getting brushed aside like 
it's nothing to do with GCC?


Cheers,
Dave Elcock