--- Comment #26 from fxcoudert at gcc dot gnu dot org 2005-10-30 13:49
---
Finally fixed by the last two commits (on both 4.0 and 4.1).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2005-10-30 13:25
---
Subject: Bug 20179
Author: fxcoudert
Date: Sun Oct 30 13:25:25 2005
New Revision: 106018
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106018
Log:
PR libfortran/20179
* io/unix.c (flush_
--- Comment #24 from fxcoudert at gcc dot gnu dot org 2005-10-30 12:48
---
Subject: Bug 20179
Author: fxcoudert
Date: Sun Oct 30 12:48:52 2005
New Revision: 106017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106017
Log:
PR libfortran/20179
* io/unix.c (flush_
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2005-10-29 12:44
---
Patch for that PR submitted
(http://gcc.gnu.org/ml/fortran/2005-10/msg00682.html).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-12
11:18 ---
(In reply to comment #21)
> It must have been some kind of regression (at least for libfortran) because
> it
> worked in the 4.0.0 release when we first tried it.
This bug was introduced while fixing an
--- Additional Comments From T dot Farago at lumc dot nl 2005-09-12 10:13
---
Ah great for fixing this, will try out as soon as the latest snapshot comes. I
had the problem that was present in comment #17, just Fortran, no C-Fortran
mix.
It must have been some kind of regression (at l
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11
18:55 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-11 18:55:16
Modified files:
gcc/testsuite : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-11
13:35 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-11 13:34:57
Modified files:
libgfortran: ChangeLog
libgfortran/io : i
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-10
16:16 ---
I should add that the code concerned is in io/transfer.c, line 1174:
/* Overwriting an existing sequential file ?
it is always safe to truncate the file on the first write */
if (g.mode == WRITIN
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-10
16:06 ---
Looking at that again, it is clear that there is a bug in the way libgfortran
handles pre-connected units. In short, the fd-based I/O library behaves like it
is the first program to access the file; this i
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-08
20:59 ---
*** Bug 23778 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-17
18:12 ---
*** Bug 22106 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-30
07:45 ---
Patch for first part of the problem applied. Keeping open according to comments
#8 to #11.
--
What|Removed |Added
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
07:42 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-30 07:42:38
Modified files:
libgfortran: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
07:38 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-30 07:38:36
Modified files:
libgfortran: ChangeLog
libgfortran/io : u
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-25
18:37 ---
In my view, interoperation implies that every part of code leaves the system in
a clean state (I/O streams flushed, FPE flags in correct state) when execution
switches to another part of code. That is wha
--- Additional Comments From stevenj at alum dot mit dot edu 2005-05-25
16:47 ---
It was already noted above that adding fflush to the user's code would fix the
output. As a quality-of-implementation issue, however, I would suggest that
libgfortran should do it.
1) Interoperating well
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-25
11:10 ---
In the modified program, calls to fflush are missing, but they are missing from
the C routine. The library does not use FILE* streams and, as far as I know, it
does its own flushing right.
The problem you
--- Additional Comments From stevenj at alum dot mit dot edu 2005-05-24
23:51 ---
I doubt that merely omitting close() from the end of the library will entirely
fix the problem. You really need to add an fflush before every output to stdio.
For example, modify ciotst.f to:
progr
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-23
17:12 ---
Good news for this PR. I located the root of the problem, which is that when the
library ends, we close() the stdout file descriptor, while the last line of
output (without newline trailing character) is n
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-22
22:09 ---
As a reply to comment 2: this is indeed a problem of mixing unix-style and
C-style I/O, but not mmap ones (this was a different PR, fixed some time ago
now: mmap is not used on standard input, output and e
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-27 18:18
---
We should probably call fflush() in the following places:
- at the beginning of a Fortran I/O operation
- at termination of the program
anywhere else?
--
What|Removed |Adde
--- Additional Comments From stevenj at fftw dot org 2005-02-23 23:17
---
Subject: Re: cannot mix C and Fortran I/O
On Wed, 23 Feb 2005, Thomas dot Koenig at online dot de wrote:
> Add "fflush(stdout);" at the end of cio.c, and things work
> as expected.
This is a workaround, but it w
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
22:54 ---
Add "fflush(stdout);" at the end of cio.c, and things work
as expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:18 ---
Actually this looks more like mixing stdio functions and unix style functions
(well mmap ones).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-23
20:08 ---
Werid.
--
What|Removed |Added
Component|fortran |libfortran
h
26 matches
Mail list logo