Re: gfortran/ifort format issues in files



Philipp E. Weidmann wrote:

I'm in the process of modifying a program that was previously compiled
with ifortran so that it will work with gfortran as well (Windows is my
testbed), and I have discovered that files written by the ifort-compiled
version will not work with the gfortran-compiled version.

There are two apparent reasons for this:

1. The program compiled with ifort terminates lines it writes to a file
with CRLF, while the gfortran version uses LF only.

The same issue comes up perpetually when transporting text files between
platforms. I make it the responsibility of my more general purpose
readers to accomodate the common variations. To put it bluntly, I do
not know why two compilers produce different line terminators, I don't
want to know, but I can write defensive reader code that should be able
to accept either.

If both compilers can read files with either terminator, as Tobias
mentioned, then the following should not be needed for your specific
case.

subroutine read_line (infile, line, ios) ! untested
implicit none
integer, intent(in ) :: infile
character(*) intent(in ) :: line ! oversize length
integer, intent(out) :: ios
character, parameter :: cr = achar(13)
integer j
read (infile, '(a)', iostat=ios) line
if (ios /= 0) return
j = len_trim (line)
if (j > 0) then
if (line(j:j) == cr) line(j:j) = ' '
end if
end subroutine read_line

Main program...

call read_line (infile, line, ios)
if (ios /= 0) handle EOF or error...
read (line, '(...)') a, b, c ...

Side note: I do not know whether the protective "if (j > 0)" is
necessary. Is the evaluation of "line(j:j)" standard conformant when j
equals 0?

2. The string written by the command

WRITE(file_unit,*) real8_value (where real8_value = 0)

is "0.000000000000000E+000" when using ifort but "0.0000000000000000"
when using gfortran (I'm not sure this actually causes any problems,
though).

Is there any way around these issues so that files written by a ifort
compiled program will be understood by a gfortran version of the same
program, and vice versa?

As others noted, both zero forms with and without the suffix should read
back correctly with fortran numeric input. Therefore, no change should
be needed for the purpose of a general fortran reader, unless you also
want the files to "look" identical.

--Dave
.



Relevant Pages

  • Re: Compilation problem with gfortran
    ... I'm trying to compile some code of mine with gfortran. ... Argument 'dydx' of pure subroutine 'rkckcontrolstep' at must ... Sun compilers accept this, but I appreciate that that isn't a definitive ...
    (comp.lang.fortran)
  • Re: OpenMP "not working" on gfortran
    ... the OpenMP code I wrote works on Mac OS X gfortran 4.5.2. ... and both of these compilers result in no speedup. ...
    (comp.lang.fortran)
  • Re: Suspicious Gfortran
    ... Fortran 77 compilers that exist, and thus doesn't mean anything in this ... problem is coming from a bug in your code, rather than a bug in gfortran. ...
    (comp.lang.fortran)
  • Re: use std=f2003 or std=f95?
    ... what do YOU mean by 'legacy'? ... Of which gfortran supports very few. ... asymmetric range is just asking for trouble. ... A LOT of compilers will negate values when it ...
    (comp.lang.fortran)
  • End of record question
    ... in the readstatement set ios to the end-of-record value. ... I'm curious to see what other compilers do, ... integer:: kount, ios ... print *, "The number of characters in the file is", kount ...
    (comp.lang.fortran)