This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Proposed patch for 4 byte unformatted record delimiters


Hi all,

There was a bug posted last January 
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303#c0)
that led to a discussion regarding the problems involved with reading the current
unformatted records with code compiled with other Fortran compilers.
I submitted a patch to buzilla to revert the size back to 4 bytes
and also proposed that the Intel approach documented here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303#c12
be used to handle record sizes larger than 2 GB. 

In summary, the delimiters for gfortran are 8 bytes rather than 4 which 
makes it impossible without reformatting to share unformatted files 
between Fortran codes on different machines compiled with different compilers. 
I did a survey and found that every other competing Fortran compiler that I tested
(Sun, SGI, Cray, g77, Intel, Portland Group) used 4 byte delimiters
rather than 8 bytes even on 64 bit machines. Intel's approach of using the
the sign of the delimiter as a continuation flag was very pragmatic I thought.

In the short term, I'd like to make the delimiters 4 bytes using something
like the proposed patch submitted to bugzilla. In the long term,
I'd recommend that the Intel approach be adopted to handle > 2GB 
record sizes.

Once this is done and a compiler flag is added to force all 
unformatted input/output IO to be big or little endian, it'll be easy to 
share unformatted files without any required formatting changes.

What is the next step? (I'm not a committer on this project right now.)

Thanks,

Rob







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]