--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-07-19 23:44
---
Fixed on 4.5.0 and 4.4.1. Thanks for bug report.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-07-19 23:26
---
Subject: Bug 40714
Author: jvdelisle
Date: Sun Jul 19 23:26:20 2009
New Revision: 149797
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149797
Log:
2009-07-19 Janne Blomqvist
Jerry DeLisle
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-07-19 23:22
---
Subject: Bug 40714
Author: jvdelisle
Date: Sun Jul 19 23:22:37 2009
New Revision: 149796
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149796
Log:
2009-07-19 Janne Blomqvist
Jerry DeLisle
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-07-19 23:10
---
Subject: Bug 40714
Author: jvdelisle
Date: Sun Jul 19 23:10:22 2009
New Revision: 149795
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149795
Log:
2009-07-19 Janne Blomqvist
Jerry DeLisle
--- Comment #9 from jb at gcc dot gnu dot org 2009-07-17 19:40 ---
Subject: Bug 40714
Author: jb
Date: Fri Jul 17 19:40:23 2009
New Revision: 149757
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149757
Log:
When finalizing I/O transfer, set current_record to 0 before returning.
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-07-16 03:23
---
Taking myself off of this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-07-16 01:31
---
I was trying to do it in hit_eof after the return from the error. I have not
figured it out yet. I will keep trying, but hope you find it first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
--- Comment #6 from jb at gcc dot gnu dot org 2009-07-15 21:42 ---
Ok, so the problem is that due to the EOF the first read hits, the
current_record marker is not properly reset to 0 at the end of the data
transfer, and from that it follows that stuff isn't correctly initialized at
the n
--- Comment #5 from jb at gcc dot gnu dot org 2009-07-15 17:19 ---
I don't get it; for some reason bytes_left_subrecord has been set to 0, hence
the seek gets messed up.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|sparc-unknown-linux-gnu |
GCC host triplet|sparc-unknown-linux-gnu |
GCC target triplet|
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-07-11 17:16
---
Another aspect of this bug. If we do this:
PROGRAM test
OPEN(UNIT=32,FILE="fort.32",STATUS="NEW",ACCESS="SEQUENTIAL",FORM="UNFORMATTED")
!READ(32,END=100)
100 CONTINUE
WRITE (32)
END PROGRAM test
We get:
$ gfc
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-07-11 15:15
---
Marked as regression. Not platform specific. I confirmed this on x86-64
Linux.
We have an illegal seek in transfer.c (next_record_w_unf) at line 2824.
--
jvdelisle at gcc dot gnu dot org changed:
13 matches
Mail list logo
