dear people, the following test code gives some unexpected results: program dummy character(len=100) :: a integer :: i,ios i=777 a(:) = ' ' read(a,*,err=999) i print *,"i=",i i=666 read(a,*,iostat=ios) i print *,"i=",i IF (ios .ne. 0) print *,"read error: ios=",ios stop 999 print *,"read error occurred" end program dummy The test program should jump to label 999 as soon as the first read statement fails. (or is this not part of the standard? seems unlikely, but I am no expert on that). However, the program stops with a runtime error. The iostat error handler in the next read statement by the way does work correct. My screen output is: >gfortran -o dummy dummy.F90 >dummy At line 7 of file dummy.F90 Fortran runtime error: End of file > The gfortran version used for testing was: >gfortran -v Using built-in specs. Target: i386-linux Configured with: ../gcc/configure --prefix=/cosmic/coudert/tmp/gfortran-20060301/irun --enable-languages=c,fortran --host=i386-linux --with-gmp=/cosmic/coudert/tmp/gfortran-20060301/gfortran_libs Thread model: posix gcc version 4.2.0 20060228 (experimental) > best regards, Jos de Kloe
Jerry, I think that this is one for you. Cheers Paul
OK, its in the queue.
The problem appears to be in error.c and occurs with file or internal I/O. error.c returns as soon as it finds a match to END condition and never looks for ERR.
I have been reviewing the f95 standard. The END condition is treated separately from the ERR condition implying maybe that its not an error. I tried the test case with Intel compiler and the result is consistent with gfortran. Anyone try this with any other compilers?
I also checked the F2003 standard. Again there are requireents given for "error condition" and "end-of-file condition. End-of-file is not an error condition. My read on this is that this is not a bug. Anyone else want to chime in, then please do. Otherwise I plan to close this bug in the next day or so.
NAG's compiler jumps to 999. kargl[203] f95 -o z -O l.f90 kargl[205] ./z read error occurred This is most likely processor dependent behavior.
When trying to compile the Starlink sources with gfortran I stumbled across this too. Unfortunately it seems that one of their autoconf tests called AC_FC_RECL_UNIT relies on the jump to the ERR label when EOR occurs. If you decide that gfortran is currently doing the right thing, I'll ask them to fix the test.
Here are the ABSOFT and IBM xlf results - [dranta:~/tests/gfortran-D] dir% f90 -o write30 write30.f [dranta:~/tests/gfortran-D] dir% write30 read error occurred [dranta:~/tests/gfortran-D] dir% xlf90 -o write30 write30.f ** dummy === End of Compilation 1 === 1501-510 Compilation successful for file write30.f. [dranta:~/tests/gfortran-D] dir% write30 1525-002 The I/O statement on the internal file cannot be completed because the end of the internal file was reached. The program will stop.
I think the votes are starting to come in on this one. I am going to get an opinion from com.lang.fortran and then proceed. I do not thing the standards disallow the desired behavior. Gfortran does the minimum now.
*** Bug 26595 has been marked as a duplicate of this bug. ***
OK, after some discussion on comp.lang.fortran it is clear tha END and EOR are not error conditions. They are there to allow for example, reading in a loop until the end of a file is reached and branching out. A true error condition would be something like a disk failure and the like. So, if an application is anticipating hitting the End-of-File deliberately then use the END parameter. Likewise for EOR. The most portable method to handle things is to use IOSTAT and test for the conditions of interest. I think the right thing to do is close this as not-a-bug.
(In reply to comment #11) > OK, after some discussion on comp.lang.fortran it is clear tha END and EOR are > not error conditions. They are there to allow for example, reading in a loop > until the end of a file is reached and branching out. A true error condition > would be something like a disk failure and the like. > > So, if an application is anticipating hitting the End-of-File deliberately then > use the END parameter. Likewise for EOR. I agree completely for the reading case. But if I have a file open for writing and try to write 8 bytes into a 4-byte record, shouldn't we jump to the ERR= label? Unfortunately there is no support for EOR= in WRITE statements. This feels a bit like an inconsistency in the standard. > The most portable method to handle things is to use IOSTAT and test for the > conditions of interest. Yes, I think I'll suggest this to the Starlink people.
If you are doing sequential writes, the write truncates the file. So if you write out 8 bytes where there were 4 before, it just overwrites and extends the file length if necessary. All data after the last write goes away. This is normal behavior. If it is DIRECT I/O you are doing, this is a different story and record sizes are fixed length.
(In reply to comment #13) > If it is DIRECT I/O you are doing, this is a different story and record sizes > are fixed length. Yes, that's what I'm talking about. Consider: PROGRAM TESTRECL IMPLICIT NONE OPEN(UNIT = 10, FILE = 'test', FORM = 'UNFORMATTED', : ACCESS = 'DIRECT', RECL = 4, ERR = 101) WRITE(UNIT=10,REC=1,ERR=101) 1d0 PRINT *,"no error detected" GOTO 102 101 PRINT *,"error detected" 102 CONTINUE CLOSE(UNIT=10, STATUS='DELETE') END ~/tmp>gfortran test3.f ~/tmp>./a.out At line 7 of file test3.f Fortran runtime error: End of record All I'm saying is that in this situation there seems to be no way to jump to some label if something goes wrong (because there is no EOR parameter for WRITE). But I agree that this is not gfortran's problem, but rather an inconsistency in the standard.
(In reply to comment #14) > All I'm saying is that in this situation there seems to be no way to jump > to some label if something goes wrong (because there is no EOR parameter > for WRITE). > But I agree that this is not gfortran's problem, but rather > an inconsistency in the standard. Dear people, thanks a lot for the discussion following my bug-report. The situation is clear to me now, and I agree this is not a real gfortran bug, but a problem in the standard. By the way, is there a way to warn/advise users to rather use the iostat keyword in stead of the err/end keywords in these problematic situations? In other words, is it possible for gfortran to detect potential problems like this, and then issue a warning, in addition to stopping with a runtime error? best regards, Jos de Kloe.
Reopening, the new test case given in Comment #14 is a valid case. Will submit patch shortly.
Subject: Bug number PR26509 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00724.html
Changing sunnary to reflect new case.
Subject: Bug 26509 Author: jvdelisle Date: Sat Mar 18 01:56:07 2006 New Revision: 112198 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112198 Log: 2006-03-17 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR libgfortran/26509 * libgfortran.h: Add ERROR_DIRECT_EOR. * runtime/error.c (translate_error): Add translation for new error. * io/transfer.c (write_buf): Add check for EOR when mode is direct access. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/error.c
Subject: Bug 26509 Author: jvdelisle Date: Sat Mar 18 01:59:50 2006 New Revision: 112199 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112199 Log: 2006-03-17 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR libgfortran/26509 gfortran.dg/write_direct_eor.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/write_direct_eor.f90 Modified: trunk/gcc/testsuite/ChangeLog
Subject: Bug 26509 Author: jvdelisle Date: Thu Mar 23 06:07:32 2006 New Revision: 112313 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112313 Log: 2006-03-22 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR libgfortran/26509 * libgfortran.h: Add ERROR_DIRECT_EOR. * runtime/error.c (translate_error): Add translation for new error. * io/transfer.c (write_buf): Add check for EOR when mode is direct access. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/transfer.c branches/gcc-4_1-branch/libgfortran/libgfortran.h branches/gcc-4_1-branch/libgfortran/runtime/error.c
Subject: Bug 26509 Author: jvdelisle Date: Thu Mar 23 06:09:14 2006 New Revision: 112314 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112314 Log: 2006-03-22 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR libgfortran/26509 gfortran.dg/write_direct_eor.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/write_direct_eor.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
Fixed on 4.1.1 and 4.2