--- 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/s
--- 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
--- 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
--- 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
IM
--- 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 writ
--- 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
--- 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.
--- 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
-
--- 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
--- 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
** d
--- 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 EO
--- 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
--- 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 e
--- 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
--- 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:
--- 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
--- 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
-
17 matches
Mail list logo
