I have a case where pgfortran 13.7 writes an incorrect record mark
at the end of an unformatted data file. This causes problems if, for
example, another code tries to BACKSPACE from the end of file.
Here is a reproducer:
PROGRAM MKGRID
C
C Illustrating a problem with pgfortran 13.7 and the last record mark
C in an unformatted file.
C Compile via: pgfortran mkgrid.f -o mkgrid
C Run via: mkgrid
C You get a file grid.in, size 224020.
C With "od -x grid.in | head -2" I see (on an Opteron 2352)
C 0000000 000c 0000 003d 0000 0033 0000 0003 0000
C 0000020 000c 0000 6af8 0003 0000 0000 0000 0000
C and "od -x grid.in | tail -3" produces for me
C 0665420 9508 fffc
C 0665424
C Note that the first record of the file contains 3 integers, so
C 12 bytes, and the record mark is accordingly 0C.
C The second record of the file contains 61*51*3*3=27999 8-byte
C reals, a total of 223992 bytes (hex 36AF8), record mark is 36AF8.
C But the last record mark is not 36AF8. This incorrect record mark
C will cause problems with a code that uses BACKSPACE, for example.
C
C This problem does not occur with pgfortran 13.5.
C
C pgfortran -V (13.7) returns:
C pgfortran 13.7-0 64-bit target on x86-64 Linux -tp gh
C pgfortran -V (13.5) returns:
C pgfortran 13.5-0 64-bit target on x86-64 Linux -tp gh
C
IMPLICIT NONE
INTEGER, PARAMETER :: JD=61,KD=51,LD=3
C
CALL DOIT(JD,KD,LD)
END
C*********************************************************
SUBROUTINE DOIT(JD,KD,LD)
IMPLICIT NONE
INTEGER, INTENT(IN) :: JD,KD,LD
C
REAL(8) :: X(JD,KD,LD),Y(JD,KD,LD),Z(JD,KD,LD)
INTEGER :: J,K,L
C
C
DO L = 1,LD
DO K = 1,KD
DO J = 1,JD
X(J,K,L) = REAL(J-1,8)
Y(J,K,L) = REAL(K-1,8)
Z(J,K,L) = REAL(L-1,8)
ENDDO
ENDDO
ENDDO
C
OPEN(UNIT=2,FILE='grid.in',STATUS='UNKNOWN',FORM='UNFORMATTED')
WRITE(2) JD,KD,LD
WRITE(2) X,Y,Z
CLOSE(UNIT=2)
C
RETURN
END