[Bug debug/26509] New: incorrect behaviour of error-handler for internal read

[Bug debug/26509] New: incorrect behaviour of error-handler for internal read

[kloedej at knmi dot nl]

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


-- 
           Summary: incorrect behaviour of error-handler for internal read
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kloedej at knmi dot nl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[pault at gcc dot gnu dot org]

------- Comment #1 from pault at gcc dot gnu dot org  2006-03-01 23:30 -------
Jerry,

I think that this is one for you.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #2 from jvdelisle at gcc dot gnu dot org  2006-03-02 03:58 -------
OK, its in the queue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #3 from jvdelisle at gcc dot gnu dot org  2006-03-03 00:37 -------
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.


-- 

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|0000-00-00 00:00:00         |2006-03-03 00:37:47
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2006-03-05 03:07 -------
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2006-03-05 03:17 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[kargl at gcc dot gnu dot org]

------- Comment #6 from kargl at gcc dot gnu dot org  2006-03-05 18:01 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[martin at mpa-garching dot mpg dot de]

------- Comment #7 from martin at mpa-garching dot mpg dot de  2006-03-06 14:33 -------
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.


-- 

martin at mpa-garching dot mpg dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |martin at mpa-garching dot
                   |                            |mpg dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[dir at lanl dot gov]

------- Comment #8 from dir at lanl dot gov  2006-03-07 16:30 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2006-03-08 01:13 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2006-03-08 01:16 -------
*** Bug 26595 has been marked as a duplicate of this bug. ***


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dir at lanl dot gov


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2006-03-09 06:39 -------
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.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[martin at mpa-garching dot mpg dot de]

------- Comment #12 from martin at mpa-garching dot mpg dot de  2006-03-09 07:12 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2006-03-09 14:56 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[martin at mpa-garching dot mpg dot de]

------- Comment #14 from martin at mpa-garching dot mpg dot de  2006-03-09 15:11 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[kloedej at knmi dot nl]

------- Comment #15 from kloedej at knmi dot nl  2006-03-10 08:27 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #16 from jvdelisle at gcc dot gnu dot org  2006-03-13 04:22 -------
Reopening, the new test case given in Comment #14 is a valid case.  Will submit
patch shortly.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

[patchapp at dberlin dot org]

------- Comment #17 from patchapp at dberlin dot org  2006-03-13 04:35 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for direct access write

[jvdelisle at gcc dot gnu dot org]

------- Comment #18 from jvdelisle at gcc dot gnu dot org  2006-03-13 04:36 -------
Changing sunnary to reflect new case.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|incorrect behaviour of      |incorrect behaviour of
                   |error-handler for internal  |error-handler for direct
                   |read                        |access write


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for direct access write

[jvdelisle at gcc dot gnu dot org]

------- Comment #19 from jvdelisle at gcc dot gnu dot org  2006-03-18 01:56 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for direct access write

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2006-03-18 01:59 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for direct access write

[jvdelisle at gcc dot gnu dot org]

------- Comment #21 from jvdelisle at gcc dot gnu dot org  2006-03-23 06:07 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for direct access write

[jvdelisle at gcc dot gnu dot org]

------- Comment #22 from jvdelisle at gcc dot gnu dot org  2006-03-23 06:09 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509

[Bug fortran/26509] incorrect behaviour of error-handler for direct access write

[jvdelisle at gcc dot gnu dot org]

------- Comment #23 from jvdelisle at gcc dot gnu dot org  2006-03-23 06:18 -------
Fixed on 4.1.1 and 4.2


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509