[about optimization]Is this a bug of gcc?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[about optimization]Is this a bug of gcc?

mojianhao


Hi experts,     I have a small test case, it got different result when compile with -O0 option and -O2 option. Is this a bug of gcc ?===============================test.c===============================#include <stdio.h>void test(double a){  double b;  b = a * 100000.00000000000;  if(a<0)    printf("a<0\n");  else if(b == 19753086420000.0000000000)  {    a += 0.000005;    printf("a+=0.000005\n");  }  printf("a=%f\n",a);}int main(){  double a=987654321/5.0;  test(a);}===========================================================result:=============================$ gcc -O0 test.c$ ./a.outa+=0.000005a=197530864.200005$ gcc -O2 test.c$ ./a.outa=197530864.200000==========================================================
my gcc version:
=============================
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404
=============================
Regards,Jianhao Mo
_________________________________________________________________
MSN圣诞礼物火热登场,免费发放中,快来领取吧!
http://im.live.cn/emoticons/?ID=18


_______________________________________________
help-gplusplus mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-gplusplus
Reply | Threaded
Open this post in threaded view
|

Re: [about optimization]Is this a bug of gcc?

Bill Braun-2
On Fri, 15 Feb 2008 20:05:06 +0800, mojianhao wrote:

> Hi experts,     I have a small test case, it got different result when
> compile with -O0 option and -O2 option. Is this a bug of gcc
> ?

[...]

Wow, that took some reformatting! What newsreader are you using?

Anyhow, no it's almost certainly not a bug. Read up on why floating point
comparisons can give unexpected results. Here's a good place to start:

http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.17

If you can get your head round that and want to dig a little deeper, try:

http://docs.sun.com/source/806-3568/ncg_goldberg.html

Regards,

--
Lionel B
_______________________________________________
help-gplusplus mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-gplusplus
Reply | Threaded
Open this post in threaded view
|

Re: [about optimization]Is this a bug of gcc?

Bernd Strieder
In reply to this post by mojianhao
Hello,

mojianhao wrote:

>
>
> Hi experts,     I have a small test case, it got different result when
> compile with -O0 option and -O2 option. Is this a bug of gcc
> ?===============================test.c===============================#include
> <stdio.h>void test(double a){  double b;  b = a * 100000.00000000000;
> if(a<0)    printf("a<0\n");  else if(b == 19753086420000.0000000000)
> {    a += 0.000005;    printf("a+=0.000005\n");  }
> printf("a=%f\n",a);}int main(){  double a=987654321/5.0;
>
test(a);}===========================================================result:=============================$
> gcc -O0 test.c$ ./a.outa+=0.000005a=197530864.200005$ gcc -O2 test.c$
> ./a.outa=197530864.200000==========================================================

At first it is a principial error in floating point arithmetic to use ==
for comparisions, because it does not give you a sensible result in
most of the cases. Look with the keyword "Floating Point arithmetic" in
the internet, e.g. Wikipedia, it should direct you to some essays one
should have read before using double. This will give you an idea of the
whole problem, and howto design your code around it. This is not
something you can solve at once for all cases, but you have to analyze
the numerical aspects of your concrete problem.

Second on ix86 processors the floating point unit has higher internal
precision than double, which makes the main difference, here. With
optimization intermediate results are kept in floating point registers
within the CPU, without optimizations they are rounded down and stored
with only double precision into some memory location, which makes the
difference. Read the docs of gcc, there are many options regarding
floating point math.

If your floating-point code is well-written, then the additional
precision of the optimized math code will not do any harm, and your
code will be easier to port to other platforms. This is the best you
can get, because there is no guarantee for extended precision at any
place. If deep in a calculation all floating point registers are in
use, the compiler will have to round some value down to double
precision and store it, to free a register.

Bernd Strieder

_______________________________________________
help-gplusplus mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-gplusplus