[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #10 from michael dot a dot richmond at nasa dot gov 2010-06-22 11:55 --- (In reply to comment #9) Michael, is this a legacy code issue? two ENDFILE in a row? It is legacy code -- michael dot a dot richmond at nasa dot gov changed: What|Removed |Added CC||michael dot a dot richmond ||at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #11 from burnus at gcc dot gnu dot org 2010-06-22 13:01 --- (In reply to comment #10) (In reply to comment #9) Michael, is this a legacy code issue? two ENDFILE in a row? It is legacy code Any idea how to best deal with this? The standard is pretty clear that it is invalid (cf. comment 0 and comment 8) - though the standard is pretty weak about what a conforming processor (i.e. compiler + run-time library) shall do for I/O, thus, there is some freedom. For the example in comment 0, several compilers print a run-time error: NAG f95 v5.1, Pathscale pathf95 3.2.99, Cray ftn 8.2.3, Open64 4.2, gfortran 4.6 If there has been no file access (write/read/open/rewind) before the first, ENDFILE, the second ENDFILE succeeds with crayftn, openf95, and pathf95. (NAG has the bogus error that the file is not open.) While (cf. comment 6) with gfortran there is an error for the second endfile. For the legacy program, would it be enough to allow - similarly to Cray/Open64/Pathscale - two ENDFILEs on unopened files? Or do you also use other endfile/endfile combinations? (If so, the program should also fail Cray/Open64/Pathscale/NAG.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #12 from michael dot a dot richmond at nasa dot gov 2010-06-22 13:02 --- I will modify my code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2010-06-23 02:37 --- Closing as fixed. If the issue of double endfile sequences pops up again we can consider putting th errors behind -std=legacy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2010-06-23 02:37 --- Closed -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #7 from michael dot a dot richmond at nasa dot gov 2010-06-20 16:14 --- The following occurs in the snapshot of June 19, but not in earlier snapshots: mrich...@msc545ux:~$ cat test.f90 PROGRAM test END FILE 10 END FILE 10 END PROGRAM test mrich...@msc545ux:~$ gfortran test.f90 mrich...@msc545ux:~$ ./a.out At line 3 of file test.f90 (unit = 10, file = 'fort.10') Fortran runtime error: Cannot perform ENDFILE on a file already positioned after the EOF marker -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #8 from kargl at gcc dot gnu dot org 2010-06-20 16:41 --- (In reply to comment #7) The following occurs in the snapshot of June 19, but not in earlier snapshots: mrich...@msc545ux:~$ cat test.f90 PROGRAM test END FILE 10 END FILE 10 END PROGRAM test mrich...@msc545ux:~$ gfortran test.f90 mrich...@msc545ux:~$ ./a.out At line 3 of file test.f90 (unit = 10, file = 'fort.10') Fortran runtime error: Cannot perform ENDFILE on a file already positioned after the EOF marker Did you read the error message? The code is invalid. For the Fortran 95 standard: After execution of an ENDFILE statement, a BACKSPACE or REWIND statement shall be used to reposition the file prior to execution of any data transfer input/output statement or ENDFILE statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-06-20 19:57 --- Michael, is this a legacy code issue? two ENDFILE in a row? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-06-19 00:58 --- Subject: Bug 44477 Author: jvdelisle Date: Sat Jun 19 00:58:28 2010 New Revision: 161020 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161020 Log: 2010-06-18 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/44477 * io/file_pos.c (st_endfile): Add check for ENDFILE when file is already positioned after the EOF marker. Use find_or_create_unit instead of find_unit. If unit is not connected, connect it and create the file with default settings. * io/transfer.c (data_transfer_init): Add check for attempted READ or WRITE when file is already positioned after the EOF marker. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-06-19 01:05 --- Subject: Bug 44477 Author: jvdelisle Date: Sat Jun 19 01:05:05 2010 New Revision: 161021 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161021 Log: 2010-06-18 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/44477 * gfortran.dg/eof_3.f90 * gfortran.dg/endfile_2.f90 * gfortran.dg/endfile_4.f90 * gfortran.dg/endfile_3.f90 Added: trunk/gcc/testsuite/gfortran.dg/endfile_3.f90 trunk/gcc/testsuite/gfortran.dg/endfile_4.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/endfile_2.f90 trunk/gcc/testsuite/gfortran.dg/eof_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-06-12 22:33 --- How about this when attempting a READ or WRITE after an ENDFILE. (original testcase) $ gfc pr44477.f90 $ ./a.out At line 5 of file pr44477.f90 (unit = 10, file = 'XXX') Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE and then this for an ENDFILE after an ENDFILE. $ ./a.out At line 5 of file pr44477.f90 (unit = 10, file = 'XXX') Fortran runtime error: Cannot perform ENDFILE on a file already positiond after the EOF marker Patch testing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-12 22:33:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-11 16:27 --- For completeness, also Cray Fortran 7.2.3 prints: A WRITE operation is invalid if the file is positioned after the end-of-file. Updated summary: - Error with: NAG f95 v5.1, Pathscale pathf95 3.2.99, Cray ftn 8.2.3, Open64 4.2 - No error with: ifort 11.1, gfortran, g95, sunf95 8.3 (sunstudio12), Portland's pgf90 v6.2 and v10.3. - Unknown: g77, ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-06-09 19:24 --- As I read this, the test case is invalid since it does not have a rewind or backspace before the write? If we want to change this to be an intended extension, I suppose we should issue a warning or error for -std= ? I want to study this more before we do anything. Regression territory here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-09 19:41 --- (In reply to comment #1) As I read this, the test case is invalid since it does not have a rewind or backspace before the write? Yes - I expect that gfortran should issue an EOR error instead of happily accepting an I/O transfer. If we want to change this to be an intended extension, I suppose we should issue a warning or error for -std= ? Well, I think we can do two things: a) Keep the current status and claim it is an extension b) Change it to match NAG f95 and Pathscale and print a run-time EoF error. (Or the equivalent for ERR=/IOSTAT=/IOMSG=.) I do not think that it makes sense to allow it for -std=(gnu/legacy) and not for -std=f(95/2003/2008). As Pathscale prints an error, there is hope that not too many programs rely on having no BACKSPACE/REWIND. Error: Pathscale 3.2.99, NAG f95 v5.1, Open64 4.2 No error: ifort 11.1, gfortran, g95, sunf95 8.3 (sunstudio12), Portland's pgf90 v6.2 and v10.3. (No idea what g77 did.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
