Re: g++ Bug? Why w/ and w/o "O3" options gives different result(g++3.3.3) for this program?

[Peng Yu]

>> #define L_x      5//10 //in the unit of \lambda\mathit{NA}
>> #define L_y      5//10 //in the unit of \lambda\mathit{NA}

I changed the above statements to
#define L_x      5.
#define L_y      5.

But the results are still different. It seems that the division isn't
the reason.


On Mon, 29 Nov 2004 08:01:57 +0100, Ulrich Eckhardt
<doomster@knuut.de> wrote:

>Peng Yu wrote:
>> I used the following command lines to compile the progrogram below.
>> However, the output of the exe files is different. The w/o O3 exe
>> produced the corrected result.
>> 
>> Is this indicate that there is a bug with g++3.3.3's O3 option? Or I
>> shouldn't use O3 in this case?
>
>[snipped floating point math]
>
>Two possible reasons:
>- the optimization affects when and where intermediate results are stored
>in registers and when they are stored in memory. Those storages could have
>different precisions, thus leading to more or less loss of precision.
>- you rely on undefined behaviour somewhere. Unless you provide a minimal
>example (which you should have anyway), I'm too lazy to analyse each and
>every line of your program - sorry.
>
>> g++-3.3 -c  -O3  -o main.o main.cc
>> g++-3.3   main.o   -o main
>> result:
>> temp = (0.0134963,0)
>> temp = (0.0132417,0)
>> 
>> g++-3.3 -c   -o main.o main.cc
>> g++-3.3   main.o   -o main
>> result:
>> temp = (0.0140056,0)
>> temp = (0.0140056,0)
>
>This looks like normal floating point rounding errors.
>
>> #define N        18//34 //should be greater than (1+s)*2 / Delta_f
>> 
>> #define L_x      5//10 //in the unit of \lambda\mathit{NA}
>> #define L_y      5//10 //in the unit of \lambda\mathit{NA}
>
>Huh? I first thought you were using integer divisions here, but those are
>really obfuscating comments, if you ask me. Anyway, use constants and not
>defines in C++.
>
>Uli