Bug 59513 - [4.8/4.9/5 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
Summary: [4.8/4.9/5 Regression] Fortran runtime error: Sequential READ or WRITE not al...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libfortran (show other bugs)
Version: 4.7.2
: P5 normal
Target Milestone: 4.8.5
Assignee: Jerry DeLisle
URL:
Keywords:
: 65565 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-12-15 18:21 UTC by ARuopp
Modified: 2015-03-30 21:12 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-12-18 00:00:00


Attachments
test script for running xfoil with output in file (124 bytes, text/plain)
2013-12-18 14:53 UTC, ARuopp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ARuopp 2013-12-15 18:21:50 UTC
Compiling xfoil, a known fortran code for airfoils works perfectly. Execution of xfoil creates an error, unfortunetly. 
Problem during execution of xfoil:
At line 652 of file ../src/iopol.f (unit = 9, file = 'polarfile_1.dat')
Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

Source code can be found for example in:
http://code.google.com/p/mjl-xfoil/source/browse/branches/osx/src/iopol.f?r=5

The compiler has problems with:
...
DO 40 IA = IA1, IA2
WRITE(LU,LINEF)
& (CPOL(IA,IPOL(KP)), KP=1, NIPOL),
& ((CPOLSD(IA,IS,JPOL(KP)), IS=1, 2*NBL), KP=1, NJPOL)
40 CONTINUE
...
?
Bug in compiler or bug in source code.
Source code works with gcc-4.3.6

Thanks in advance
Comment 1 Jerry DeLisle 2013-12-15 22:19:19 UTC
This depends a lot on what is in the file polarfile_1.dat.

Can you reduce the code to a small failing example?

Also, on the snippet attached, what do you mean the compiler has a problem? Likewise can you send a complete small example of valid code?  I assume you are getting some sort of compilation error, but not sure what you mean.
Comment 2 ARuopp 2013-12-15 22:33:04 UTC
Hi,

compilation of code works without any problems.
Only if I execute the code, the problem exists with this error message.
The file 'polarfile_1.dat' is written during executing xfoil, but no values are written into the file.

I tried to fix it, since error message during run points to mentioned code line in iopol.f, at line 652 (see previous error message with link):

DO IA = IA1, IA2
     OPEN(LU,FILE=FNPOL,STATUS='OLD',POSITION='APPEND',ERR=90)
        
       WRITE(LU,LINEF)
     &         (CPOL(IA,IPOL(KP)), KP=1, NIPOL),
    &        ((CPOLSD(IA,IS,JPOL(KP)), IS=1, 2*NBL), KP=1, NJPOL)
     CLOSE(LU)
     ENDDO

But this didn't work, too.

Why is it working with an older gcc-version?

I will try to make a small code example but I'm not a fortran expert.
Comment 3 ARuopp 2013-12-16 00:02:39 UTC
Inserting the backspace:

BACKSPACE(LU)

before loop

      DO 40 IA = IA1, IA2
        WRITE(LU,LINEF)
     &         (CPOL(IA,IPOL(KP)), KP=1, NIPOL),
     &        ((CPOLSD(IA,IS,JPOL(KP)), IS=1, 2*NBL), KP=1, NJPOL)
   40 CONTINUE

works now.

I guess, gfortran standard changed?
I'm not sure, because older gcc-versions worked with this code without any problems.
Comment 4 Dominique d'Humieres 2013-12-17 18:48:06 UTC
I installed foil today through fink and noticed that the fortran files are compiled (gfortran 4.8.2) with '-O0 -fdefault-real-8 -fdefault-integer-8'. Are you using these options?
Comment 5 ARuopp 2013-12-18 14:53:36 UTC
Created attachment 31469 [details]
test script for running xfoil with output in file

this is a test script for testing xfoil in running in batch mode.
what it does:
starting xfoil
loading a test profil naca 0018
setting values
calculating some lift and drag values for different aoa
writing solution in polarfile_1.dat
then it finishes


in shell execute the program like this:
xfoil < xfoil.naca.run1
Comment 6 ARuopp 2013-12-18 14:56:22 UTC
Hi,

thank you very much for your effort.
Compiling is not the problem. 
Try to execute the script, which I attached. 
Without the "backspace" modification, xfoil ends with the error message:

At line 655 of file ../src/iopol.f (unit = 9, file = 'polarfile_1.dat')
Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

Is your xfoil running without the modification?
Comment 7 ARuopp 2013-12-18 14:57:55 UTC
Execute with:
xfoil < xfoil.naca.run1
Comment 8 Dominique d'Humieres 2013-12-18 15:04:14 UTC
Running your script on xfoil built by fink (gfortran 4.8.2) ends with the reported error:

  10   rms: 0.6268E-05   max: -.8920E-04   D at   83  1
       a =  0.000      CL = -0.0000
      Cm =  0.0000     CD =  0.00773   =>   CDf =  0.00549    CDp =  0.00224

 Point added to stored polar  1
At line 652 of file ../src/iopol.f (unit = 9, file = 'polarfile_1.dat')
Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE

I'll try to find some time to build foil myself with earlier versions (don't hold your breath!-).
Comment 9 ARuopp 2013-12-18 15:19:15 UTC
BTW: 
"At line 652 of file...."is correct.

Line 655 was including some comments from my side... I didn't want to confuse....
Comment 10 Dominique d'Humieres 2013-12-18 16:23:01 UTC
I also see the problem with gfortran 4.7.3.
Comment 11 Dominique d'Humieres 2013-12-18 16:35:27 UTC
No error with gfortran  4.4.7, 4.5.4, but gfortran 4.6.4 gives the error. So marked as a 4.7/4.8/4.9 regression. 

When I'll have learnt how to build foil myself, I'll try to do some bisection and some reduction.
Comment 12 Jerry DeLisle 2014-04-21 19:41:23 UTC
Dominique, any progress on this one? Shall I look into it?
Comment 13 giorgio.signorini 2014-05-27 13:01:40 UTC
(In reply to Dominique d'Humieres from comment #11)
> No error with gfortran  4.4.7, 4.5.4, but gfortran 4.6.4 gives the error. So
> marked as a 4.7/4.8/4.9 regression. 
> 
> When I'll have learnt how to build foil myself, I'll try to do some
> bisection and some reduction.

I think this is connected to bug 44477 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477), which has been fixed in gfortran 4.6.

Could it be that the POSITION='APPEND' option acts like a sequence of READs up to EOF, which in gfortran < 4.6 did a silent, non-standard BACKSPACE?
Comment 14 Dominique d'Humieres 2014-07-11 17:33:06 UTC
Still present at r212457, updating the summary.
Comment 15 Dominique d'Humieres 2014-07-12 11:22:52 UTC
Reduced test

      CHARACTER*29 LINE1, LINE2
      CHARACTER*128 LINEL, LINED, LINEF, FNPOL
      INTEGER :: i, IA, IA1, IA2, NBL, NIPOL, NJPOL, LU
      INTEGER :: IRETYP = 1, IMATYP = 1
      INTEGER :: IPOL(6) = [(i,i=1,6)], JPOL(6) = [(i,i=1,6)]
      REAL :: CPOL(2,6), CPOLSD(2,4,6)

      IA1 = 1
      IA2 = 1
      NBL = 1
      NIPOL = 5
      NJPOL = 1
      CPOL = 0.0
      CPOL(1,1:5) = [0.00000000, -1.12720882E-05, 7.72975758E-03,      &
                     2.23584706E-03, 2.04495814E-06]
      CPOLSD = 0.0
      CPOLSD(1,1,1) = 0.591679573
      CPOLSD(1,2,1) = 0.591711044

      FNPOL = 'xfoil.res'
      LINEF = '(1X,F7.3  ,F9.4  ,F10.5 ,F10.5 ,F9.4  ,F9.4  ,F9.4  )'
      OPEN(LU,FILE=FNPOL,STATUS='UNKNOWN')
      CALL BOTTOM(LU)

      do 40 IA = IA1, IA2
        WRITE(LU,LINEF) (CPOL(IA,IPOL(KP)), KP=1, NIPOL),             &
             ((CPOLSD(IA,IS,JPOL(KP)), IS=1, 2*NBL), KP=1, NJPOL)
   40 CONTINUE

      CLOSE(LU)

      END

      SUBROUTINE BOTTOM(LU)
      CHARACTER*1 DUMMY

 10   READ(LU,1000,END=90,ERR=90) DUMMY
 1000 FORMAT(A)
      GO TO 10

 90   RETURN
      END

The 'culprit' is the line

CALL BOTTOM(LU)

The code works with gcc 4.5.0 r157963, but not with gcc 4.8.3.
Comment 16 Dominique d'Humieres 2014-07-12 11:39:40 UTC
The change occurred between revisions r158253 (2010-04-13, "working?") and r162456 (2010-07-23, error). It could be r161021 (pr44477).
Comment 17 Dominique d'Humieres 2014-07-12 13:11:51 UTC
I wonder if the gfortran present behavior is not the *RIGHT* one. It is obviously for any READ following 'CALL BOTTOM(LU)', I am not 100% confident for WRITE. Not that replacing

 90   RETURN

with

 90   BACKSPACE(LU)
      RETURN

allows the test to run.
Comment 18 Dominique d'Humieres 2014-07-12 13:24:10 UTC
> It could be r161021 (pr44477).

Read r161020 and the error message has been introduced in libgfortran/io/transfer.c at this revision.
Comment 19 Dominique d'Humieres 2014-07-12 18:02:25 UTC
I have rebuilt a clean Xfoil with the following patch

--- src_orig/xpol.f	2007-09-16 03:56:31.000000000 +0200
+++ src/xpol.f	2014-07-12 19:55:40.000000000 +0200
@@ -606,8 +606,7 @@ C---- add point to save file
         IPOL(NIPOL) = ICH
        ENDIF
 C
-       OPEN(LU,FILE=PFNAME(IP),STATUS='OLD')
-       CALL BOTTOM(LU)
+       OPEN(LU,FILE=PFNAME(IP),STATUS='OLD', POSITION = 'APPEND')
        IA = NAPOL(IP)
        CALL POLWRIT(LU,' ',ERROR, .FALSE.,
      &              NAX, IA,IA, CPOL(1,1,IP), IPOL,NIPOL,
@@ -648,8 +647,8 @@ C
       BETA = SQRT(1.0 - MINF**2)
       BFAC = 0.5*MINF**2 / (1.0 + BETA)
 C
-      OPEN(LU,FILE=PFNAMX(IP),STATUS='OLD',FORM='UNFORMATTED')
-      CALL BOTTOMX(LU)
+      OPEN(LU,FILE=PFNAMX(IP),STATUS='OLD',FORM='UNFORMATTED',
+     &     POSITION='APPEND')
 C
 C---- write integrated forces to unformatted dump file
       IF(LVISC) THEN
@@ -920,26 +919,3 @@ C
       RETURN
       END ! POLAXI
 
-
-
-      SUBROUTINE BOTTOM(LU)
-      CHARACTER*1 DUMMY
-C
- 10   READ(LU,1000,END=90,ERR=90) DUMMY
- 1000 FORMAT(A)
-      GO TO 10
-C
- 90   RETURN
-      END
-
-
-      SUBROUTINE BOTTOMX(LU)
-      CHARACTER*1 DUMMY
-C
- 10   READ(LU,END=90,ERR=90) DUMMY
-      GO TO 10
-C
- 90   RETURN
-      END
-
-

and the script works fine. 

Note that the following patch is also needed

diff -Naur Xfoil_orig/src/pplot.f Xfoil/src/pplot.f
--- Xfoil_orig/src/pplot.f	2008-04-07 17:05:29.000000000 -0400
+++ Xfoil/srcpplot.f	2008-04-09 18:50:59.000000000 -0400
@@ -36,7 +36,7 @@
       PROGRAM PPLOT
       INCLUDE 'PPLOT.INC'
 C
-      LOGICAL ERROR, LGETFN
+      LOGICAL ERROR, LGETFN, LERR
       REAL RINP(10)
       REAL CPOLO(NAX,IPTOT,NPX), VPOLO(NAX,2,NPX)
 C

otherwise gfortran complains about INTEGER instead of LOGICAL for 'IF(LERR)'.
Comment 20 Jerry DeLisle 2014-07-12 19:43:25 UTC
I think gfortran behavior is correct.  The problem with the sample code is in the lack of handling in subroutine BOTTOM.  The loop is reading past the end of the file. END= is not a true error condition, but a file condition. One can not just ignore it, the read has gone past the End-Of-File marker.  It is necessary to position the file.

Also, this is really not good coding practice to do nothing on ERR=. ERR= really is an ERROR.


      SUBROUTINE BOTTOM(LU)
      CHARACTER*1 DUMMY

 10   READ(LU,1000,END=90,ERR=90) DUMMY
 1000 FORMAT(A)
      GO TO 10

 90   BACKSPACE(LU)
      RETURN
      END

Fortran 2003 Standard:  9.2.3.2 File position prior to data transfer

If the file contains an endfile record, the file shall not be positioned after the endfile record prior to data transfer. However, a REWIND or BACKSPACE statement may be used to reposition the file.

Based on this I believe the resolution of this bug is 'INVALID'.  The bug is in xfoil.  We could choose to disable the error on -std=legacy.  I do not know what the old g77 did.  I will check that.
Comment 21 Dominique d'Humieres 2014-07-15 16:39:47 UTC
(In reply to Jerry DeLisle from comment #20)
> Based on this I believe the resolution of this bug is 'INVALID'. ...

I fully agree. If there is no objection before next Wednesday (July 23, 21014), I'll close the PR.
Comment 22 Manfred Schwarb 2014-07-15 21:43:50 UTC
I just encountered the same issue, with some convoluted legacy code.
The scheme seems to be the same:

      READ(lun,END=100) buffer
100   WRITE(lun,*) "whatever"

As the used code definitely was used in practice, mainly before the year
2000, I guess that older compiler supported this.

And yes, the BACKSPACE() trick works. However, common sense suggest
that with END= we are at the end of the file. This sounds a bit like the
old joke, where you have a room with 5 people, you are taking 6 out, so
someone has to go in for the room to be empty. Beyond EOF simply does
not exist.

Jerry, concerning your cited standard:
"If the file contains an endfile record" suggests that there is some
special marker in the file to be read/written.
In this example, we are doing some formatted IO to a plain text file,
there are no special markers.
Do I miss something?

What does/should ftell() report in such a case? That we are one
character beyond EOF?
Comment 23 Dominique d'Humieres 2014-07-15 22:07:12 UTC
> Jerry, concerning your cited standard:
> "If the file contains an endfile record" suggests that there is some
> special marker in the file to be read/written.

From the standard:

> NOTE 9.2
> An endfile record does not necessarily have any physical embodiment. The
> processor may use a record count or other means to register the position
> of the file at the time an ENDFILE statement is executed, so that it can take
> appropriate action when that position is reached again during a read
> operation. The endfile record, however it is implemented, is considered
> to exist for the BACKSPACE statement (9.8.2).
Comment 24 Jerry DeLisle 2014-07-16 01:45:11 UTC
(In reply to Manfred Schwarb from comment #22)
--- snip ---

> Jerry, concerning your cited standard:
> "If the file contains an endfile record" suggests that there is some
> special marker in the file to be read/written.
> In this example, we are doing some formatted IO to a plain text file,
> there are no special markers.
> Do I miss something?
> 
> What does/should ftell() report in such a case? That we are one
> character beyond EOF?

I think Dominique has answered as far as the physical aspect.

FTELL just returns the current physical location.
Comment 25 Manfred Schwarb 2014-07-16 10:36:59 UTC
OK, thanks Jerry and Dominique for the explanations.

It seems the correct syntax then is:
      READ(lun,END=100) buffer
      GOTO 101
100   BACKSPACE(lun)
101   WRITE(lun,*) "whatever"

Not that the above code would make sense to me as a mere user,
but it works both with gfortran 4.5 and 4.6 upwards.

I just wrote a small test program, the output is identical for
gfortran 4.5 and 4.6+:
      CHARACTER*20 buffer,buffer2
      INTEGER i

      buffer=""
      buffer2=""
      OPEN(10,FILE="test.txt")
      WRITE(10,'(a)') "0123456789"
      CLOSE(10)

      OPEN(10,FILE="test.txt",POSITION="APPEND")
      CALL ftell(10,i)
      print*,"file position in append mode:",i
      CLOSE(10)

      OPEN(10,FILE="test.txt")
      READ(10,'(a20)') buffer
      print*,"X",buffer,"X"
      CALL ftell(10,i)
      print*,"file position after reading buffer:",i
CC      BACKSPACE(10)  ! then below write will overwrite first line
      WRITE(10,'(a)') "ABC"
      CLOSE(10)
      CALL system("cat test.txt")

      OPEN(10,FILE="test.txt")
      WRITE(10,'(a)') "0123456789"
      CLOSE(10)

      OPEN(10,FILE="test.txt")
      READ(10,'(a20)',END=100) buffer,buffer2
      GOTO 101
  100 CALL ftell(10,i)
      print*,"END clause encountered: file position:",i
      BACKSPACE(10)
  101 CALL ftell(10,i)
      print*,"file position:",i
      print*,"X",buffer,"X",buffer2,"X"
      WRITE(10,'(a)') "ABC"
      CLOSE(10)
      CALL system("cat test.txt")

      END
Comment 26 Manfred Schwarb 2014-07-16 10:49:33 UTC
I just tested g77.
As suspected, g77 is in line with gfortran 4.5.
It happily accepts the following and does not throw an error
in the END clause case:
      READ(lun,END=100) buffer
100   WRITE(lun,*) "whatever"
Comment 27 Jakub Jelinek 2014-12-19 13:30:57 UTC
GCC 4.8.4 has been released.
Comment 28 Jerry DeLisle 2015-03-22 18:43:23 UTC
Author: jvdelisle
Date: Sun Mar 22 18:42:52 2015
New Revision: 221572

URL: https://gcc.gnu.org/viewcvs?rev=221572&root=gcc&view=rev
Log:
2015-03-22 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/59513
	* io/transfer.c (data_transfer_init): Do not error for
	-std=legacy.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/transfer.c
Comment 29 Jerry DeLisle 2015-03-22 21:37:45 UTC
Author: jvdelisle
Date: Sun Mar 22 21:37:13 2015
New Revision: 221575

URL: https://gcc.gnu.org/viewcvs?rev=221575&root=gcc&view=rev
Log:
2015-03-22 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/59513
	* gfortran.texi (Read/Write after EOF marker): New information.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.texi
Comment 30 Jerry DeLisle 2015-03-22 21:39:24 UTC
Fixed on 5.0, will backport in a few days.
Comment 31 Dominique d'Humieres 2015-03-25 18:27:46 UTC
*** Bug 65565 has been marked as a duplicate of this bug. ***
Comment 32 Jerry DeLisle 2015-03-30 16:52:09 UTC
Author: jvdelisle
Date: Mon Mar 30 16:51:37 2015
New Revision: 221772

URL: https://gcc.gnu.org/viewcvs?rev=221772&root=gcc&view=rev
Log:
2015-03-30 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/59513
	* io/transfer.c (data_transfer_init): Do not error for
	-std=legacy.

Modified:
    branches/gcc-4_9-branch/libgfortran/ChangeLog
    branches/gcc-4_9-branch/libgfortran/io/transfer.c
Comment 33 Jerry DeLisle 2015-03-30 20:48:11 UTC
Author: jvdelisle
Date: Mon Mar 30 20:47:40 2015
New Revision: 221778

URL: https://gcc.gnu.org/viewcvs?rev=221778&root=gcc&view=rev
Log:
2015-03-30 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libgfortran/59513
	* io/transfer.c (data_transfer_init): Do not error for
	-std=legacy.

Modified:
    branches/gcc-4_8-branch/libgfortran/ChangeLog
    branches/gcc-4_8-branch/libgfortran/io/transfer.c
Comment 34 Jerry DeLisle 2015-03-30 21:12:33 UTC
Fixed on 4.8, 4.9, and 5.0 Closing.