This is the mail archive of the
mailing list for the GCC project.
64 bit fortran unformatted on Opteron -- incompatible with 32 unformatted
- From: Kyon <kyon at verizon dot net>
- To: gcc-help at gcc dot gnu dot org
- Date: Tue, 15 Jun 2004 09:59:25 -0700
- Subject: 64 bit fortran unformatted on Opteron -- incompatible with 32 unformatted
- Organization: K 9 Bone Admiration Society
- Reply-to: tunaboy2 at verizon dot net
I hope this is the correct list to send to, as it deals with gcc-g77 and not
the g95 project. Here's the deal:
I am compiling fortran77 code I run on the athlon/pentium platform, and am
now moving over to the Opteron. This code reads and writes fortran
unformatted files when it starts up and ends. A great deal of time has
already been spent creating these fortran unformatted files. (This is CFD,
and the files are grid and solution files).
The MIPS sgi machines had similar 32 and 64 bit flavors, and on those
machines you could run either 32bit or 64bit codes and read the same
unformatted files seamlessly. On the Opterton, this is not the case. I can
use code compiled -m32, but when I use -m64, the code does not real the files
correctly. I am specifying exactly the form of the data to be read, e.g.
I compile this code chunk under -m32 and it will correctly read the file. I
compile under -m64 and it doesn't. The reason is the record length marker(or
whatever the proper term for this is) which is the first item of the
unformatted file. I figured this out by writing a similar little stub
program to make a fortran unformatted file, noting that I can read -m64
generated unformatted with -m64 code, and -m32 generated unformatted with
-m32 code, but I could not switch them. I then looked at the generated files
and noted that the first either 4 or 8 bytes was the record length for -m32
and -m64 respectively, and then the files were identical from that point on.
What the heck: here's the code to generate a file to read
NJ = 101
NK = 101
NL = 3
You can compile this with either -m32 or -m64 and note the changes.
Now, is this what was intended? It would certainly be nice if the -m64 code
would read -m32 generated unformatted the way the SGI's used to work.
If this is the wrong forum, please point me to the right place...