[Bug fortran/47694] New: Fortran read from named pipe fails to read all available data

[Bug fortran/47694] New: Fortran read from named pipe fails to read all available data

[David.Duffy at qimr dot edu.au]

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

           Summary: Fortran read from named pipe fails to read all
                    available data
           Product: gcc
           Version: fortran-dev
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: David.Duffy@qimr.edu.au


I am mucking around with named pipes and read().

program testpipe
  integer :: ios, n
  character (len=1024) :: lin
  open(7, file='tmpfifo')
  n=0
  do
    read(7,'(a)', iostat=ios) lin
    if (ios /= 0) exit
    n=n+1
    write(*,*) n, trim(lin)
  end do
end program testpipe

Using gfortran (4.6.0 20110209), this stops before reading all data in the pipe
unless it is further topped up from the other end ;) As written, no such
problem with sunf95, g95, openf95 (runs until pipe emptied, then waits for
more).  I presume it is a buffering problem somewhere.

Linux tinonee 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686
GNU/Linux

Cheers, David Duffy.

[Bug fortran/47694] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-11 14:34:55 UTC ---
Seems to work for me on x86-64-linux using
gcc version 4.6.0 20110202 (experimental) [trunk revision 169512]

$ mkfifo tmpfifo
$ gfortran test.f90
$ ./a.out

and then in a different terminal window:
$ cat > tmpfifo

All items I type there appear after I hit "enter" as output of "./a.out".

 * * *

Hmm, seems as if I can reproduce the problem: If I paste (middle click) the
following text into the "cat > tmpfifo"

"Using gfortran (4.6.0 20110209), this stops before reading all data in the
pipe
unless it is further topped up from the other end ;) As written, no such
problem with sunf95, g95, openf95 (runs until pipe emptied, then waits for
more).  I presume it is a buffering problem somewhere."

(that's 4 lines with line breaks after "pipe", "such", "for")

I get:
 "1 Using gfortran (4.6.0 20110209), this stops before reading all data in the
pipe"

if I then hit "enter" another time, I get:

 "2 unless it is further topped up from the other end ;) As written, no such"


Expected: Lines 1 to 3 are shown right a way without waiting for two additional
line breaks. That's what I also get with ifort.

[Bug fortran/47694] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-11 20:06:41 UTC ---
See http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gfortran/Runtime.html#Runtime

and try these.

[Bug fortran/47694] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-11 20:33:34 UTC ---
(In reply to comment #2)
> See http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gfortran/Runtime.html#Runtime
> and try these.

   GFORTRAN_UNBUFFERED_ALL=1 ./a.out

does not help (result unchanged).

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
      Known to work|                            |4.1.2
   Target Milestone|---                         |4.6.0
            Summary|Fortran read from named     |[4.3/4.4/4.5/4.6
                   |pipe fails to read all      |Regression] Fortran read
                   |available data              |from named pipe fails to
                   |                            |read all available data
      Known to fail|                            |4.3.4, 4.4.0, 4.5.1, 4.6.0

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-11 21:36:39 UTC ---
Set as regression as it works with GCC 4.1 but fails with GCC 4.3 to 4.6.

 * * *

(In reply to comment #3)
>    GFORTRAN_UNBUFFERED_ALL=1 ./a.out
> does not help (result unchanged).

Actually, it is not too surprising that the result does not change as
libgfortran/io/unix.c has:

  if (!(S_ISREG (statbuf.st_mode) || S_ISBLK (statbuf.st_mode))
      || options.all_unbuffered
[...]
    raw_init (s);
  else
    buf_init (s);

Thus, there should be no buffering.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.02.14 14:54:08
     Ever Confirmed|0                           |1

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-14 14:54:08 UTC ---
I have now added in io/unix.c's raw_read the following:

  fprintf(stderr, "raw_read - buf size: %d\n", (int) nbyte);
  n = read (s->fd, buf, nbyte);
  fprintf(stderr, " .... read %d, '", (int) n);
  for (i = 0; i < n; i++)
    fprintf(stderr, "%c", ((char*) buf)[i]);
  fprintf(stderr, "'\n");
  return n;

If I now paste in "cat > tmpfifo" the following:
line 1
line 2
line 3
line 4 <no linebreak>


I see on the other side:

raw_read - buf size: 1024
 .... read 14, 'line 1
line 2
'
           1 line 1
raw_read - buf size: 1017
 .... read 7, 'line 3
'
           2 line 2
raw_read - buf size: 1017

Thus, "raw_read" reads two lines at once - but gfortran only outputs one line.
For the next Fortran READ, "raw-read" is again invoked although in the buffer
there is still the second half of the first read: The second line including a
terminating line break. Thus, the Fortran output lags one line behind.


Expected: gfortran first uses the buffer and invokes read_raw only if the
buffer does not contain sufficient data (e.g. not a full line ending with a
line break).

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-14 15:13:44 UTC ---
If one enables fbuf debugging (FBUF_DEBUG in fbuf.c), one sees:

fbuf_read done: fbuf_debug pos: 0, act: 14, buf: ''LINE 1
LINE 2
''
Then the expected:
           1 LINE 1
is printed.


The next call to fbuf_read shows the correct buffer, which could directly be
used:

fbuf_read, len 1024: fbuf_debug pos: 0, act: 7, buf: ''LINE 2
''

But nevertheless, sread is invoked again:

fbuf_alloc len 1024, fbuf_debug pos: 0, act: 7, buf: ''LINE 2
''
reading 1017 bytes starting at 7 fbuf_debug pos: 0, act: 1024, buf: ''LINE 2
LINE 2

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-14 21:23:27 UTC ---
The data is read via:
 read_a -> read_block_form -> read_sf -> fbuf_read

read_sf has the nice comment: "When reading sequential formatted records we
have a problem.  We don't know how long the line is until we read the trailing
newline, and we don't want to read too much. [...] Given this, the solution is
to read a byte at a time, stopping if we hit the newline."

However, the first action it does is:

  /* Read data into format buffer and scan through it.  */
  lorig = *length;
  base = p = fbuf_read (dtp->u.p.current_unit, length);

length is 1024 (cf. comment 0). Thus, [if (oldpos + *len > oldact)], it invokes
sread.

I think the solution is to read from the buffer until its end - and then call,
if needed, fbuf_read for the remaining "length-already_read" characters.
(I do not see whether there are additional issues, but this should solve at
least one issue.)

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-14 21:58:30 UTC ---
Created attachment 23344
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23344
Hackish brute-force patch

The attached patch fixes the issue by calling in read_sf fbuf_read once per
single character. I think that's the only proper solution, though the way it is
currently handled is surely slow - and the patch is not nicely written.

Janne and/or Jerry, could you have a look?

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-15 00:57:36 UTC ---
I started to look at this problem a few days ago and will give it some priority
in the next few days.  I do think we can fix this in a more efficient manner
(knock on wood).  Let's see what we come up with. Janne, keep me posted on
anything you do so we don't waste each others time.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-15 09:07:58 UTC ---
(In reply to comment #8)
> Created attachment 23344 [details]
> Hackish brute-force patch

Note: This patch causes (not very surprisingly) file-read problems, e.g. for
Polyhedron's aermod.f90 (which reads aermod.inp). Thus, do not use it for
production code.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #11 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-15 09:42:12 UTC ---
Unfortunately I don't think I'll have time to look into it this week.

As can be seen from Tobias patch, reading one character at a time is very slow.
But, the comment in read_sf() is wrong, it's not actually needed to read one
character at a time; what we need to do is to handle short reads correctly.

One fix, I suspect, would be to convert read_sf() to use fbuf_getc() instead,
which gives the impression of reading a character at a time, even though fbuf
takes care of doing buffered reads in the background. But in order to do that,
the read_sf() API needs to be changed so that a buffer is passed as an
argument, and this buffer is then filled with data, rather than returning a
pointer to the fbuf buffer.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-17 01:07:20 UTC ---
the "file" is not seekable so the position eturne by seek always returns zero. 
I plane to see if we can do something with the seek to get it to return a
position within fbuf.  If that does not seem reasonable, I will go with the
fbuf_fgetc approach which should be fairly efficient.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #13 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-17 12:13:53 UTC ---
(In reply to comment #12)
> the "file" is not seekable so the position eturne by seek always returns zero. 

If you mean sseek(), don't count on that; the unix.c:raw_*() functions are
more-or-less 1:1 mappings to the POSIX IO API, where the lseek() documentation

http://pubs.opengroup.org/onlinepubs/9699919799/functions/lseek.html

says

"The behavior of lseek() on devices which are incapable of seeking is
implementation-defined. The value of the file offset associated with such a
device is undefined."

and also in the errors section there is:

[ESPIPE]
    The fildes argument is associated with a pipe, FIFO, or socket.

FWIW, the need to handle seeking within a record (due to T* and some other edit
descriptors) was one of the main motivations to introduce the fbuf layer in the
first place.

> I plane to see if we can do something with the seek to get it to return a
> position within fbuf.  If that does not seem reasonable, I will go with the
> fbuf_fgetc approach which should be fairly efficient.

As I recall, the problem with using fbuf_getc() in read_sf() is that the
read_sf() API change would propagate such that one would need to modify all the
read_x() functions in read.c to pass a buffer as a parameter rather than
getting a pointer into the fbuf buffer to read from. 

I suspect this particular bug could be fixed by some smallish changes to
read_sf() to handle short reads better, but perhaps we need to more
fundamentally think about what kind of API we want to have for formatted IO?

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-17 12:54:58 UTC ---
In reply to comment #13: Well, I was thinking fbuf_seek.  I came to the
conclusion that I do not want to change the API for read_sf for the reasons you
state.

I am now focusing on read_sf.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23344|0                           |1
        is obsolete|                            |
         AssignedTo|unassigned at gcc dot       |jvdelisle at gcc dot
                   |gnu.org                     |gnu.org

--- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-02-19 00:12:06 UTC ---
Created attachment 23402
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23402
A proposed final patch

This patch has been regression tested and passes.  The more testing by others,
the better.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #16 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-22 19:43:10 UTC ---
Patch using the fbuf_getc approach:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01475.html

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #17 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-23 06:59:54 UTC ---
Author: jb
Date: Wed Feb 23 06:59:51 2011
New Revision: 170432

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432
Log:
PR 47694 Read from named pipe fails

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/fbuf.h
    trunk/libgfortran/io/transfer.c

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #18 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-23 07:11:55 UTC ---
Fixed on trunk. Keeping this PR open in order to remind us to

1) Backport to older releases once we have some experience on trunk.

2) Fix io/read.c(read_x) in the same way to use fbuf_getc instead of fbuf_read.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

--- Comment #19 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-24 12:51:38 UTC ---
(In reply to comment #18)
> Fixed on trunk. Keeping this PR open in order to remind us to
> 1) Backport to older releases once we have some experience on trunk.

Breaks SPEC CPU 2000's 187.facerec, see PR 47878.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

--- Comment #20 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-24 14:17:40 UTC ---
Some random thoughts looking at the patch
(http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432) - probably not
helping at all with the regressions:

I find the following a bit dubious - thought it was also odd before:

+  base = fbuf_getptr (dtp->u.p.current_unit);
   if (base == NULL)
     return NULL;

The first line is effectively:
  base = (char*) (u->fbuf->buf + u->fbuf->pos);

Thus, base is only NULL if "u->fbuf->buf" == NULL *and* u->fbuf->pos == 0. I am
not sure about the second part, though I think in practice, fbuf_init has
(hopefully!) always been called and thus it will never be NULL.


+      if (q == EOF)

Does this always work? We have in "static inline int fbuf_getc (gfc_unit * u)":
    return (unsigned char) u->fbuf->buf[u->fbuf->pos++];
and "q" is "int".

The issue I see is the following (quote from POSIX's fgetc(3p)):
"If the integer value returned by fgetc() is stored into a variable of type
char and then compared against the  integer constant EOF, the comparison may
never succeed, because sign-extension of a variable of type char on widening to
integer is implementation-defined."

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #21 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-24 15:04:42 UTC ---
(In reply to comment #20)
> Some random thoughts looking at the patch
> (http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170432) - probably not
> helping at all with the regressions:
> 
> I find the following a bit dubious - thought it was also odd before:
> 
> +  base = fbuf_getptr (dtp->u.p.current_unit);
>    if (base == NULL)
>      return NULL;
> 
> The first line is effectively:
>   base = (char*) (u->fbuf->buf + u->fbuf->pos);
> 
> Thus, base is only NULL if "u->fbuf->buf" == NULL *and* u->fbuf->pos == 0. I am
> not sure about the second part, though I think in practice, fbuf_init has
> (hopefully!) always been called and thus it will never be NULL.

I agree, that NULL check can be removed.

> 
> 
> +      if (q == EOF)
> 
> Does this always work? We have in "static inline int fbuf_getc (gfc_unit * u)":
>     return (unsigned char) u->fbuf->buf[u->fbuf->pos++];
> and "q" is "int".
> 
> The issue I see is the following (quote from POSIX's fgetc(3p)):
> "If the integer value returned by fgetc() is stored into a variable of type
> char and then compared against the  integer constant EOF, the comparison may
> never succeed, because sign-extension of a variable of type char on widening to
> integer is implementation-defined."

You're missing the whole picture. The definition of fbuf_getc in fbuf.h is

static inline int
fbuf_getc (gfc_unit * u)
{
  if (u->fbuf->pos < u->fbuf->act)
    return (unsigned char) u->fbuf->buf[u->fbuf->pos++];
  return fbuf_getc_refill (u);
}

That is, the inlined fast path is for the case when there is data available in
the buffer. If there isn't data, it falls back to fbuf_getc_refill, where if
filling the buffer with more data fails EOF is returned, otherwise the next
character cast to unsigned char. 

FWIW, if you dig into the glibc sources, the getc() macro is implemented in a
very similar way.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jb at gcc dot gnu.org]

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

--- Comment #22 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-02-24 15:08:00 UTC ---
(In reply to comment #21)
> (In reply to comment #20)
> > +      if (q == EOF)
> > 
> > Does this always work? We have in "static inline int fbuf_getc (gfc_unit * u)":
> >     return (unsigned char) u->fbuf->buf[u->fbuf->pos++];
> > and "q" is "int".
> > 
> > The issue I see is the following (quote from POSIX's fgetc(3p)):
> > "If the integer value returned by fgetc() is stored into a variable of type
> > char and then compared against the  integer constant EOF, the comparison may
> > never succeed, because sign-extension of a variable of type char on widening to
> > integer is implementation-defined."
> 
> You're missing the whole picture. The definition of fbuf_getc in fbuf.h is
> 
> static inline int
> fbuf_getc (gfc_unit * u)
> {
>   if (u->fbuf->pos < u->fbuf->act)
>     return (unsigned char) u->fbuf->buf[u->fbuf->pos++];
>   return fbuf_getc_refill (u);
> }
> 
> That is, the inlined fast path is for the case when there is data available in
> the buffer. If there isn't data, it falls back to fbuf_getc_refill, where if
> filling the buffer with more data fails EOF is returned, otherwise the next
> character cast to unsigned char. 

That is, there is never some kind of EOF character in the buffer, rather EOF is
a special error value which is returned when there is no more data available.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #23 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-04 14:42:57 UTC ---
Final fix was added here:

http://gcc.gnu.org/viewcvs?view=revision&revision=170476

For reference when we back port this to 4.5.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #24 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-05 00:05:40 UTC ---
Author: jvdelisle
Date: Sat Mar  5 00:05:34 2011
New Revision: 170692

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170692
Log:
2011-03-04  Jakub Jelinek  <jakub@redhat.com>

    Backport from mainline
    PR fortran/47878
    * io/transfer.c (read_sf): Call fbuf_getptr only at the end,
    and subtract n, dtp->u.p.sf_seen_eor and seen_comma from it.

2011-03-04  Janne Blomqvist  <jb@gcc.gnu.org>
        Jerry DeLisle    <jvdelisle@gcc.gnu.org>

    Backport from mainline
    PR libfortran/47694
    * io/fbuf.h (fbuf_getptr): New inline function.
    * io/transfer.c (read_sf): Use fbuf_getptr and fbuf_getc to scan
    through the string instead of fbuf_read.

2011-03-04  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    Backport from mainline
    PR libgfortran/47878
    * gfortran.dg/pr47878.f90: New test.

Added:
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr47878.f90
Modified:
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/libgfortran/ChangeLog
    branches/gcc-4_5-branch/libgfortran/io/fbuf.h
    branches/gcc-4_5-branch/libgfortran/io/transfer.c

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #25 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-05 00:21:21 UTC ---
Fixed on 4.5 and trunk, I am preparing a back port for 4.4.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[burnus at gcc dot gnu.org]

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

--- Comment #26 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-03-05 09:53:54 UTC ---
What's about the following? I assume that's a 4.7 item?

(In reply to comment #18)
> 2) Fix io/read.c(read_x) in the same way to use fbuf_getc instead of fbuf_read.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #27 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-05 15:40:12 UTC ---
(In reply to comment #26)
> What's about the following? I assume that's a 4.7 item?
> 
> (In reply to comment #18)
> > 2) Fix io/read.c(read_x) in the same way to use fbuf_getc instead of fbuf_read.

Depends.  I have not looked yet.  If its simple, maybe 4.6. On the other hand,
I don't have a test case exhibiting a bug.

Also, the bug manifests itself in 4.3, but 4.3 precedes the use of fbuf so it
would be a whole different patch, so I am not going to backport to 4.3.  4.4
does not have fbuf.h, but I put the relevant parts in io.h and it tests fine. I
think 4.4 is as far as we go back.

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #28 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-07 03:08:12 UTC ---
Author: jvdelisle
Date: Mon Mar  7 03:08:08 2011
New Revision: 170732

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170732
Log:
2011-03-06  Jakub Jelinek  <jakub@redhat.com>

    Backport from mainline
    PR fortran/47878
    * io/transfer.c (read_sf): Call fbuf_getptr only at the end,
    and subtract n, dtp->u.p.sf_seen_eor and seen_comma from it.

2011-03-06  Janne Blomqvist  <jb@gcc.gnu.org>
        Jerry DeLisle    <jvdelisle@gcc.gnu.org>

    Backport from mainline
    PR libfortran/47694
    * io/io.h (fbuf_getptr): New inline function.
    * io/transfer.c (read_sf): Use fbuf_getptr and fbuf_getc to scan
    through the string instead of fbuf_read.

Modified:
    branches/gcc-4_4-branch/libgfortran/ChangeLog
    branches/gcc-4_4-branch/libgfortran/io/io.h
    branches/gcc-4_4-branch/libgfortran/io/transfer.c

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #29 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-07 03:16:33 UTC ---
Fixed  on 4.4, 4.5, and 4.6.  Closing

[Bug fortran/47694] [4.3/4.4/4.5/4.6 Regression] Fortran read from named pipe fails to read all available data

[jvdelisle at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #30 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-03-07 03:17:17 UTC ---
Closing