public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* 64 bit fortran unformatted on Opteron -- incompatible with 32 unformatted
@ 2004-06-15 16:59 Kyon
  2004-06-15 21:48 ` Toon Moene
  0 siblings, 1 reply; 2+ messages in thread
From: Kyon @ 2004-06-15 16:59 UTC (permalink / raw)
  To: gcc-help

Folks,

	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.

	INTEGER*4 NJ,NK,NL
        open(unit=1,file='grid.in',form='unformatted',status='old')
        read(1)NJ,NK,NL
        close(1)
        write(*,*)nj,nk,nl
        end

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

        INTEGER*4 NJ,NK,NL
        NJ = 101
        NK = 101
        NL = 3
        open(unit=1,file='grid.in',form='unformatted',status='new')
        write(1)NJ,NK,NL
        close(1)
        end

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...

Mike 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: 64 bit fortran unformatted on Opteron -- incompatible with 32 unformatted
  2004-06-15 16:59 64 bit fortran unformatted on Opteron -- incompatible with 32 unformatted Kyon
@ 2004-06-15 21:48 ` Toon Moene
  0 siblings, 0 replies; 2+ messages in thread
From: Toon Moene @ 2004-06-15 21:48 UTC (permalink / raw)
  To: tunaboy2; +Cc: gcc-help

Kyon wrote:

 > 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.

Yep, unfortunately, we figured this out too late to fix it:  It would 
make it impossible for people on 64-bit systems using GCC/g77 version n 
to read their files generated by programs compiled by GCC/g77 version 
n-1.  We thought this was the lesser problem of the two, so we kept the 
(unfortunate) code in libf2c.

Now an interesting question is how we are going to treat this with 
gfortran:  On the one hand we can do it right (use one record length 
size on 32-bit and 64-bit systems), but then people on 64-bit systems 
can't read their g77 generated unformatted files - or we could do the 
same as libf2c and be stuck with the above problem.

On the third hand, I have received requests for 64-bit record lengths on 
either system so that larger-than-2-Gbyte records are possible.

So many choices, so little time ....

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-06-15 21:48 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-15 16:59 64 bit fortran unformatted on Opteron -- incompatible with 32 unformatted Kyon
2004-06-15 21:48 ` Toon Moene

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).