https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Sun Dec 9 18:54:47 2018
New Revision: 266929
URL: https://gcc.gnu.org/viewcvs?rev=266929&root=gcc&view=rev
Log:
2018-12-09 Thomas Koenig
PR fortran/88411
* io/trans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
--- Comment #7 from Thomas Koenig ---
This looks like it could do the trick:
Index: io/transfer.c
===
--- io
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
--- Comment #6 from Thomas Koenig ---
Something glaringly obvious just struck me: The test case
has synchronous writes for a file which is opened asynchronously.
This may or may not have been intended. It is certainly a bug
not to get this righ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
--- Comment #5 from Thomas Koenig ---
Hm, maybe something else.
It seems we're actually writing direct access files in the
main thread, even when using asynchronous I/O.
Hmm...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
--- Comment #4 from Thomas Koenig ---
The problem appears to be that the record length is set to zero
a file with the same unit number is opened again.
Hmm... some more digging is needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
--- Comment #1 from Harald Anlauf ---
Further data points:
- removing the asynchronous='yes' for the first OPEN has no effect,
- removing the asynchronous='yes' for the second OPEN makes the problem
disappear
