Bug 52251 - Nonadvancing I/O and the t edit descriptor
Summary: Nonadvancing I/O and the t edit descriptor
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Jerry DeLisle
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2012-02-14 20:11 UTC by Tobias Burnus
Modified: 2018-07-02 21:21 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-04-27 00:00:00


Attachments
A patch to fix this. (409 bytes, patch)
2015-07-04 23:19 UTC, Jerry DeLisle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2012-02-14 20:11:30 UTC
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."
Comment 1 Tobias Burnus 2012-02-14 20:29:50 UTC
I have now also ask at the J3 mailing list:
  http://j3-fortran.org/pipermail/j3/2012-February/005054.html
Comment 2 Tobias Burnus 2012-02-15 07:18:42 UTC
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.
Comment 3 Tobias Burnus 2012-02-15 10:10:22 UTC
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.
Comment 4 Dominique d'Humieres 2014-04-27 10:48:52 UTC
Still present at r209835 (4.10).
Comment 5 Jerry DeLisle 2015-04-23 19:46:09 UTC
Working on it.
Comment 6 Jerry DeLisle 2015-07-04 23:19:09 UTC
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.
Comment 7 Jerry DeLisle 2015-11-23 00:41:22 UTC
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
Comment 8 Jerry DeLisle 2015-11-24 16:59:07 UTC
Fixed on trunk. Should we backport to 5 branch?
Comment 9 Jerry DeLisle 2015-12-05 18:03:21 UTC
Closing, fixed on trunk.