[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Jerry DeLisle --- Fixed on trunk, closing.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 --- Comment #10 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:41e767c482fc903ca5d54014b034c7526dbf8f1c commit r14-9681-g41e767c482fc903ca5d54014b034c7526dbf8f1c Author: Jerry DeLisle Date: Tue Mar 26 16:44:17 2024 -0700 libgfortran: Fix file position after ENDFILE statement. PR libfortran/107031 libgfortran/ChangeLog: * io/file_pos.c (st_endfile): Remove call to next_record(). gcc/testsuite/ChangeLog: * gfortran.dg/endfile_5.f90: New test.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 --- Comment #9 from Jerry DeLisle --- The following trivial patch changes gfortran behavior and regression tests Ok on x86_64. I will see if I can come up with a test case to catch this. diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c index 2bc05b293f8..d169961f997 100644 --- a/libgfortran/io/file_pos.c +++ b/libgfortran/io/file_pos.c @@ -352,7 +352,6 @@ st_endfile (st_parameter_filepos *fpp) dtp.common = fpp->common; memset (, 0, sizeof (dtp.u.p)); dtp.u.p.current_unit = u; - next_record (, 1); } unit_truncate (u, stell (u->s), >common);
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 Jerry DeLisle changed: What|Removed |Added Status|WAITING |NEW Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- Thankyou for information, I will take a look.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 urbanjost at comcast dot net changed: What|Removed |Added CC||urbanjost at comcast dot net --- Comment #7 from urbanjost at comcast dot net --- FYI: A parallel discussion of this issue came to the consensus that the file should be truncating to five lines, not six. The conversation included members of the Fortran Standards Committee. https://fortran-lang.discourse.group/t/clarification-on-expected-behavior-of-endfile/
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #3) > (In reply to kargl from comment #2) > > gfortran's current behavior is correct. > > > > > >12.3.4.4 File position after data transfer > > > >In all other cases, the file is positioned after the record just > >read or written and that record becomes the preceding record. > > > >12.8.3 ENDFILE statement > > > >Execution of an ENDFILE statement for a file connected for sequential > >access writes an endfile record as the next record of the file. > > > > After reading '5', the file is position at the record that contains '6'. > > So, ENDIFLE writes the endfile record after the record with '6'. > > Hmm, interpretation of text? > Yes, it is interpretation. Let denote the start of record and the end of the record. One has 567 After reading '5', the file is positioned to after that record. If * denotes the current file, then one can have 5*6 or 5*6 Both meet the requirement of 12.3.4.4. Now by 12.8.3, the endfile will give 5EOF while the latter would give 5*6EOF.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 --- Comment #5 from Steve Kargl --- On Sun, Sep 25, 2022 at 08:56:22PM +, kargl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 > > --- Comment #4 from kargl at gcc dot gnu.org --- > (In reply to anlauf from comment #3) > > (In reply to kargl from comment #2) > > > gfortran's current behavior is correct. > > > > > > > > >12.3.4.4 File position after data transfer > > > > > >In all other cases, the file is positioned after the record just > > >read or written and that record becomes the preceding record. > > > > > >12.8.3 ENDFILE statement > > > > > >Execution of an ENDFILE statement for a file connected for sequential > > >access writes an endfile record as the next record of the file. > > > > > > After reading '5', the file is position at the record that contains '6'. > > > So, ENDIFLE writes the endfile record after the record with '6'. > > > > Hmm, interpretation of text? > > > > I read "as the next record", not "after the next record". > > > > gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn. > > If the current record contain '6', the next record contains '7'. > 'next' does not mean 'current' in the English language. It means > something that 'follows'. > Further confusion, maybe? 12.3.4 File position 12.3.4.1 General ... Let n be the number of records in the file. ... If 1 <= i < n and a file is positioned within the ith record or between the ith and (i + 1)th record, the (i + 1)th record is the next record.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #3) > (In reply to kargl from comment #2) > > gfortran's current behavior is correct. > > > > > >12.3.4.4 File position after data transfer > > > >In all other cases, the file is positioned after the record just > >read or written and that record becomes the preceding record. > > > >12.8.3 ENDFILE statement > > > >Execution of an ENDFILE statement for a file connected for sequential > >access writes an endfile record as the next record of the file. > > > > After reading '5', the file is position at the record that contains '6'. > > So, ENDIFLE writes the endfile record after the record with '6'. > > Hmm, interpretation of text? > > I read "as the next record", not "after the next record". > > gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn. If the current record contain '6', the next record contains '7'. 'next' does not mean 'current' in the English language. It means something that 'follows'.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > gfortran's current behavior is correct. > > >12.3.4.4 File position after data transfer > >In all other cases, the file is positioned after the record just >read or written and that record becomes the preceding record. > >12.8.3 ENDFILE statement > >Execution of an ENDFILE statement for a file connected for sequential >access writes an endfile record as the next record of the file. > > After reading '5', the file is position at the record that contains '6'. > So, ENDIFLE writes the endfile record after the record with '6'. Hmm, interpretation of text? I read "as the next record", not "after the next record". gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Status|NEW |WAITING --- Comment #2 from kargl at gcc dot gnu.org --- gfortran's current behavior is correct. 12.3.4.4 File position after data transfer In all other cases, the file is positioned after the record just read or written and that record becomes the preceding record. 12.8.3 ENDFILE statement Execution of an ENDFILE statement for a file connected for sequential access writes an endfile record as the next record of the file. After reading '5', the file is position at the record that contains '6'. So, ENDIFLE writes the endfile record after the record with '6'.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|fortran |libfortran Ever confirmed|0 |1 Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-25 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. It appears that this issue exists since 2005.
