--- Comment #15 from jvdelisle at gcc dot gnu dot org 2006-03-15 05:34
---
Subject: Bug 26499
Author: jvdelisle
Date: Wed Mar 15 05:34:05 2006
New Revision: 112076
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112076
Log:
2006-03-14 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2006-03-15 05:40
---
Subject: Bug 26499
Author: jvdelisle
Date: Wed Mar 15 05:40:20 2006
New Revision: 112077
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112077
Log:
2006-03-14 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-03-15 07:10
---
Fixed on 4.2 before, now fixed on 4.1.1 as well.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-03-10 03:15
---
Subject: Bug 26499
Author: jvdelisle
Date: Fri Mar 10 03:15:36 2006
New Revision: 111924
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111924
Log:
2006-03-09 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-03-10 03:23
---
Subject: Bug 26499
Author: jvdelisle
Date: Fri Mar 10 03:23:28 2006
New Revision: 111925
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111925
Log:
2006-03-09 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #12 from dir at lanl dot gov 2006-03-06 14:06 ---
It works great on the Macintosh. Now, if someone could just get the windows
version of gfortran under MinGW to pass these I/O tests, it might become
usuable. My programs compile under MinGW, but they all crash when I try to
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-03-05 06:20
---
Final patch here:
http://gcc.gnu.org/ml/fortran/2006-03/msg00046.html
Waiting for OK to commit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26499
--- Comment #9 from dir at lanl dot gov 2006-03-03 14:51 ---
That got the one in comment #7. Here is the next one -
[dranta:~/tests/gfortran-D] dir% g77 -o write29 write29.f
[dranta:~/tests/gfortran-D] dir% write29
[dranta:~/tests/gfortran-D] dir% gfortran -o write29 write29.f
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-03-03 23:05
---
The case in Comment #9 is also very simple. I got myself again. I saw this
before, but because I did not have a test case that failed, I left it alone.
With this fix in file_pos.c all of Dale's rewind tests
--- Comment #7 from dir at lanl dot gov 2006-03-02 14:02 ---
Hi Jerry,
As you may have guessed, I added this problem to the things that my program
looks for. You got that one and all the ones like it, but here is another one
from a slightly different class (rewind after reading
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-03-03 01:51
---
Add a flush just before the truncate in st_write_done and comment seven is
fixed.I had it in there at first, then I took it out to see if things would
still work, and they did with the cases I had. A revised
--- Comment #3 from dir at lanl dot gov 2006-03-01 13:50 ---
Hi Jerry,
The program does
3 writes - eof after record 3 - write pointer after record 3
2 backspaces - eof after record 3 - write pointer after record 1
1 write - eof after record 2 - write
--- Comment #4 from jvdelisle at verizon dot net 2006-03-01 14:36 ---
Subject: Re: gfortran - End of File incorrectly
positioned after binary I/O.
dir at lanl dot gov wrote:
--- Comment #3 from dir at lanl dot gov 2006-03-01 13:50 ---
Hi Jerry,
The program does
--- Comment #5 from dir at lanl dot gov 2006-03-01 17:37 ---
With a sequential access file, the eof is always positioned after the location
of the last write. Thus, a file needs to be truncated to that location when it
is closed, otherwise you are saving data that is beyond the end of
--- Comment #6 from patchapp at dberlin dot org 2006-03-02 06:35 ---
Subject: Bug number PR26499
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/msg00115.html
--
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-03-01 00:57
---
Confirmed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-01 07:19
---
Take a closer look at this folks. The program should jump to line 250 on the
fourth READ. If you change the test line to: if(iat.ne.eof+1)then you will see
that gfortran is correctly jumping out on the fourth
17 matches
Mail list logo
