g77 i586 different optimization for real*4 in common/dimension

Tim Prince timothyprince@sbcglobal.net
Tue Apr 8 13:41:00 GMT 2003


On Tuesday 08 April 2003 00:57, Dmitry A. Bukin wrote:
> Hello,
>
> We have noticed that a program compiled by g77 with optimization
> produces different results in array of real*4 dependent on
> the location of this array (whether it is in common or in dimension).
> GNU Fortran (GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) 3.2 20020903 (Red
> Hat Linux 8.0 3.2-7)

> compilation command line arguments and output:
> unix% g77 --verbose -O -g -fno-ugly -fugly-assumed -Wall -Wsurprising -W
> -malign-double -fforce-mem -fforce-addr -fno-automatic -finit-local-zero
> -fdollar-ok -Wuninitialized -ffixed-line-length-none -o test1 test1.for
>
> This problem disappeared when we used option -ffloat-store,
> but we are afraid of the performance hit of this option...
> The replacement of real*4 with real*8 solves the problem also,
> but this solution is not suitable, as we want our results
> to be the same as they were on the older platform/compiler.
>
> The solution with setting _FPU_DOUBLE bit in the control word of FPU
> does not solve the problem.
>

If this is a problem for you, you will want to be using either a more 
accurate or a more Biblical value for Pi.  If you examine the generated code, 
you will see, surprisingly, that the compiler is treating 3.1416/180. as a 
double precision value in the second version only, contrary to the standard 
translation of your code.  Changing either the level of optimization or the 
target instruction set makes the double precision go away.  If you wished to 
make double precision go away in fpcw, you would change your mask by 1 bit.

-- 
Tim Prince



More information about the Gcc-bugs mailing list