[Bug fortran/52251] New: Nonadvancing I/O and the t edit descriptor

[Bug fortran/52251] New: Nonadvancing I/O and the t edit descriptor

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251

             Bug #: 52251
           Summary: Nonadvancing I/O and the t edit descriptor
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: jvdelisle@gcc.gnu.org


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 \fle 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."

[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 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

[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 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.

[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 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.

[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org

--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Working on it.