Re: Compiling in 32 vs 64 platform problem

I've recently get the same problem with Intel fortran compiler while I was runing some comparisons between ifort (ia32 and ia64) and XLF (IBM RS6000). I think the problem is related to :
> Most variables in the program are declared as real <name of variable>
> with a few declared as real*8. There are dozens of different common
> blocks through the program.

I've discovered that floating point constants in ifort seems to be REAL and lead to a loss of precision when initializing a DOUBLE PRECISION variable.
DOUBLE PRECISION t=2.33D0
is not the same than
DOUBLE PRECISION t=2.33

Same problems seems to occur with intinsic functions (I saw it with sin())
Try to compile with -r8 flag to set all your floating point variables _and_ constants to DOUBLE PRECISION (except if some are REAL*4 in the code...) et test again. Your data will be more homogeneous in precision.

But this as nothing to do with 32/64 bits programs. The differences may be related to cpu architecture and troncature of the stored values of your variables.

Patrick


Peter wrote:
Hello,

I have a several thousand-lines code in f77 that I want to port to 64
bit architecture machines. I use Intel Fortran compiler version 8.1.
with the following command line:

ifort -c -O2

followed by linking of the different object files.

The program is self-contained in the sense that it does not require
any external libraries (except the portability library specified by
the -Vaxlib switch at linking time). Compilation and linking seem to
go smoothly but the results obtained from the program differ from
those that I get on 32 bit architecture machines. Comparing the result
files on both systems one can see difference in values that start on
the second decimal place between the 32 bit results and the 64 bit
results. For example:

64 bit results:

7.5 1 0.664139E-01 1
0.238612E+00
0.531925E-02
0.154969E-01
0.382009E-01

32 bit results:
7.5 1 0.581779E-01 1
0.239058E+00
0.543676E-02
0.155693E-01
0.383326E-01

I have compiled the same code on many different 32 bit machines (also
with the same compiler) and the results usually do not differ by that
much. Thus, I am concerned that something else is happening here but I
am not sure what.

Most variables in the program are declared as real <name of variable>
with a few declared as real*8. There are dozens of different common
blocks through the program.

So far I have thought that the problem may be related to:

a) the size of a real in a 32 bit machine is perhaps different than in
the 64 bit machine and what I am looking at is some sort of rounding
off problem.

b) Common blocks. I have heard that sometimes there may be alignment
problems.

In either case I am not sure how to solve the problem. I was wondering
if anyone could offer some insights into the problem and how to solve
it. Thanks in advance.

Peter
.

Relevant Pages

  • Re: Conformance
    ... They give a precision of approx 30 decimal digits ... This only increases the precision, not the range, and there are tricky ... Does your compiler pad qfloats to 512 bits or do your refer to ... qfloat s = 3.1415965358979323846264338327950288419Q; ...
    (comp.std.c)
  • Re: What does 32 bit application mean?
    ... Does this means that the compiler is ... Thus it corresponds to the register ... > assembler for 32 bit architecture. ... > [On all the modern machines I know, the register size and the address ...
    (comp.compilers)
  • Re: Numerical accuracy of C++ and Fortran programs on 32 bit machines
    ... ....snip prior discussion and example where average error of extension of ... > double precision constants 1.2D0 etc. (and at the moment this seems to ... > compiler should issue a warning, but in my opinion it should not be so ... The /fpconstant option requests that a single-precision constant ...
    (comp.programming)
  • Re: Atmel AVR assembler
    ... so I decided to write my own assembler. ... >> extensive testing on various machines and operating environments. ... where I may not be able to legally restore the compiler toolset. ... supporting tools where the code was developed using Lattice C around ...
    (comp.arch.embedded)
  • Re: Chipmunk Basic arrays (Attn: Ron Nicholson)
    ... it is a PITA for the programmer because it ... specific precision, then you need to be able to specify that to the compiler. ... when the compiler forced him to choose a data type. ...
    (comp.lang.basic.misc)