From http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5eff88b12c9bd24f gfortran (and sunf95) print for the following program: "Hello", starting in column 1. However, other compilers (g95, ifort, NAG, PathScale, Open64, crayftn, pgf95) print "Hello" in column 25. Write( *, '( t25 )', Advance = 'No' ) Write( *, '( "Hello" )' ) Richard Maine thinks that gfortran's version is correct, but he fails to nail it in the standard and is a bit unsure. Dick Hendrickson thinks the other compilers are correct. Seems to make sense to fill an interpretation request. Glancing at the standard, I am inclined to the interpretation that there should be blanks. * * * From the Fortran 2008 standard: "9.3.4.2 Advancing and nonadvancing input/output" [...] "A nonadvancing input/output statement may position a record file at a character position within the current record, or a subsequent record (10.8.2). Using nonadvancing input/output, it is possible to read or write a record of the file by a sequence of input/output statements, each accessing a portion of the record. It is also possible to read variable-length records and be notified of their lengths. If a nonadvancing output statement leaves a file positioned within a current record and no further output statement is executed for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND statement is executed for it, the effect is as if the output statement were the corresponding advancing output statement." "10.5 Positioning by format control After each data edit descriptor or character string edit descriptor is processed, the file is positioned after the last character read or written in the current record. After each T, TL, TR, or X edit descriptor is processed, the file is positioned as described in 10.8.1. [...]" "10.8.1 Position editing The T, TL, TR, and X edit descriptors specify the position at which the next character will be transmitted to or from the record. If any character skipped by a T, TL, TR, or X edit descriptor is of type nondefault character, and the unit is a default character internal file or an external non-Unicode file, the result of that position editing is processor dependent. The position specified by a T edit descriptor may be in either direction from the current position. [...] [...] On output, a T, TL, TR, or X edit descriptor does not by itself cause characters to be transmitted and therefore does not by itself affect the length of the record. If characters are transmitted to positions at or after the position specified by a T, TL, TR, or X edit descriptor, positions skipped and not previously filled are filled with blanks. The result is as if the entire record were initially filled with blanks. On output, a character in the record may be replaced. However, a T, TL, TR, or X edit descriptor never directly causes a character already placed in the record to be replaced. Such edit descriptors may result in positioning such that subsequent editing causes a replacement. 10.8.1.1 T, TL, and TR editing The left tab limit affects file positioning by the T and TL edit descriptors. Immediately prior to nonchild data transfer (9.6.4.8.2), the left tab limit becomes defined as the character position of the current record or the current position of the stream file. If, during data transfer, the file is positioned to another record, the left tab limit becomes defined as character position one of that record. The Tn edit descriptor indicates that the transmission of the next character to or from a record is to occur at the nth character position of the record, relative to the left tab limit." [Informative] "C.6.2 Nonadvancing input/output (9.3.4.2) Data transfer statements affect the positioning of an external file. In Fortran 77, if no error or end-of-file condition exists, the file is positioned after the record just read or written and that record becomes the preceding record. This part of ISO/IEC 1539 contains the record positioning ADVANCE= specifier in a data transfer statement that provides the capability of maintaining a position within the current record from one formatted data transfer statement to the next data transfer statement. The value NO provides this capability. The value YES positions the le after the record just read or written. The default is YES. The tab edit descriptor and the slash are still appropriate for use with this type of record access but the tab cannot reposition before the left tab limit. [...] In an implementation of nonadvancing input/output in which a nonadvancing write to a terminal device causes immediate display of the output, such a write can be used as a mechanism to output a prompt. [...] This part of ISO/IEC 1539 does not require that an implementation of nonadvancing input/output operate in this manner. For example, an implementation of nonadvancing output in which the display of the output is deferred until the current record is complete is also standard-conforming. Such an implementation will not, however, allow a prompting mechanism of this kind to operate."
I have now also ask at the J3 mailing list: http://j3-fortran.org/pipermail/j3/2012-February/005054.html
Answer: It's a bug in gfortran and sunf95 Bob Corbett wrote: > I filed an interpretation request on this issue in 1998. [...] > I suspect that Oracle Solaris Studio Fortran is one of the implementations > that you saw write "Hello" in column 1. A defect report was filed against > Sun Fortran years ago. I had hoped to fix the problem in the 12.3 release, > but I ran out of time because I had to work on more important bugs. The approved interpretation request has the following, cf. 000027 "Sequential formatted I/O: position of the left tab" at http://j3-fortran.org/doc/year/02/02-006c2.txt : > QUESTION: > When a file is positioned within a record at the start of sequential > formatted I/O, where is the left tab limit (see Section 10.6.1.1)? Is it at > the start of the record or at the point where the file was positioned at > the start of execution of the statement? > > ANSWER: > The left tab limit is the point where the file was positioned at the start > of execution of the statement. > > DISCUSSION: > This follows from the second sentence of 10.6.1.1, which states "Immediately > prior to data transfer, the left tab limit becomes defined as the character > position of the current record." > > EDITS: None.
I wonder whether that's a [4.2-4.7] regression (backported to 4.1) due to the patch for PR 25463. (I have not recompiled to check.) My impression is that without that patch, commen 0 might be correctly handled. The patch in PR 25463 fixed the case: write (*,'(A)',advance="no") 'ab' write (*,'(T1,A)') 'c' (should be "abc" and not "c" or "ab c" or ...) I think one needs to save the skips (for advanced='no') somewhere in dtp->u.p.current_unit as the dtp->u.p.skips are currently gone after _gfortran_st_write_done, if I understand the code correctly.
Still present at r209835 (4.10).
Working on it.
Created attachment 35911 [details] A patch to fix this. This patch issues the tab spacing based on spaces previously skipped pending transfer of data. In the test case, there is no data transferred so we were skipping handling the skips.
Author: jvdelisle Date: Mon Nov 23 00:40:51 2015 New Revision: 230734 URL: https://gcc.gnu.org/viewcvs?rev=230734&root=gcc&view=rev Log: 2015-11-22 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR libfortran/52251 * io/transfer.c (formatted_transfer_scalar_write): Reset skips count. (finalize_transfer): For ADVANCE_NO, emit pending spaces and reset the skip count. 2015-11-22 Jerry DeLisle <jvdelisle@gcc.gnu.org> * gfortran.dg/fmt_t_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_t_8.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
Fixed on trunk. Should we backport to 5 branch?
Closing, fixed on trunk.