[Bug fortran/38430] New: [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[Bug fortran/38430] New: [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

With revision 142513 these test passed.
>From revision 142516 and on, these tests have failed as follows
(together with related tests:

Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
...
FAIL: gfortran.dg/streamio_1.f90  -O0  execution test
FAIL: gfortran.dg/streamio_10.f90  -O0  execution test
FAIL: gfortran.dg/streamio_14.f90  -O0  execution test
FAIL: gfortran.dg/streamio_14.f90  -O1  execution test
FAIL: gfortran.dg/streamio_16.f90  -O0  execution test
FAIL: gfortran.dg/streamio_2.f90  -O0  execution test
FAIL: gfortran.dg/streamio_6.f90  -O0  execution test
FAIL: gfortran.dg/streamio_8.f90  -O0  execution test


With the messages in the logfile being all similar:

PASS: gfortran.dg/streamio_1.f90  -O0  (test for excess errors)
At line 13 of file
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/streamio_1.f90 (unit = 11,
file = 'fort.11')^M
Fortran runtime error: POS=specifier too large^M
FAIL: gfortran.dg/streamio_1.f90  -O0  execution test

Remember, this is one of those targets with no truncation support
(neither ftruncate nor chsize).  Is that related?
(Not evident by a glance at streamio_1.f90 but perhaps the library itself
does.)
Is this perhaps due to lack of some other support?  Looks very much
seek-related.

Author of suspect patches in the revision range CC:ed, but I'll assign myself
this PR while I investigate whether there's a deficiency in the (l)seek support
of this target, particularly with -D_FILE_OFFSET_BITS=64.


-- 
           Summary: [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2,
                    6 now fails
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: hp at gcc dot gnu dot org
        ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-12-06 19:16:54
               date|                            |


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[jvdelisle at gcc dot gnu dot org]

------- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-12-06 19:35 -------
This very well could be the ftruncate issue since I did modify the code path. 
however, it seems that if these test cases worked before then we are
unnecessarily doing the ftruncate for the pos= code path in data_transfer_init.

I am looking at that right now.


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

------- Comment #2 from hp at gcc dot gnu dot org  2008-12-06 20:09 -------
If there was an ftruncate call in the execution path, then I'd see the
"required ftruncate or chsize support not present" message in the log, and I
don't.


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[jvdelisle at gcc dot gnu dot org]

------- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-12-06 21:01 -------
I did miss an fbuf_flush.  I am not sure why it matters unless it is avoiding
some actual disk operations for us. Try this and let me know.

@@ -2146,7 +2155,10 @@ data_transfer_init (st_parameter_dt *dtp
              /* Required for compatibility between 4.3 and 4.4 runtime. Check
              to see if we might be reading what we wrote before  */
              if (dtp->u.p.current_unit->mode == WRITING)
-               flush(dtp->u.p.current_unit->s);
+               {
+                 fbuf_flush (dtp->u.p.current_unit, 1);      
+                 flush(dtp->u.p.current_unit->s);
+               }

              if (dtp->pos < file_length (dtp->u.p.current_unit->s))
                dtp->u.p.current_unit->endfile = NO_ENDFILE;


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

------- Comment #4 from hp at gcc dot gnu dot org  2008-12-06 21:15 -------
(In reply to comment #3)
> Try this and let me know.

Will do.


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

------- Comment #5 from hp at gcc dot gnu dot org  2008-12-06 21:33 -------
Sorry, it didn't help.


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

------- Comment #6 from hp at gcc dot gnu dot org  2008-12-07 21:42 -------
I noticed something odd while looking at simulator traces: running the
test-case streamio_1 at -O1 (passing) yielded a different execution path than
at -O0 (failing) *in the library*.  At -O0, no write system calls were done for
that file but at -O1, I see libgfortran flushes and write calls.  So, it looks
like internal inconsistency rather than target system oddness.

Anyway, I've been somewhat blind.
This gfortran.dg is a "torture-testsuite"; it iterates over -O0, -O1 etc. and
most failures happen at -O0 *only* so it should not have take more than a
glance to see that it cannot (for sane bugs) be a fault of the target system
(e.g. the lseek implementation).  Instead, I believe the observed internal
inconsistency is due to a missing initialization on part of libgfortran, which
should explain why this isn't visible on all systems.  Running streamio_1 from
r142537 at -O1 using valgrind on a native i686-unknown-linux-gnu (where FWIW no
gfortran test FAILs) seems to support this theory:
"env LD_LIBRARY_PATH=<copy this from your gfortran.log> valgrind -q
./streamio_1.exe" yields:
--9635-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x55
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF47: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x8048863: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF47: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x80488B9: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF4D: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x80488B9: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF58: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x80488B9: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF47: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x804890F: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF4D: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x804890F: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF58: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x804890F: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF47: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x8048965: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF4D: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x8048965: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF58: finalize_transfer (transfer.c:2962)
==9635==    by 0x40ABFE0: _gfortran_st_write_done (transfer.c:3130)
==9635==    by 0x8048965: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40AD378: data_transfer_init (transfer.c:2144)
==9635==    by 0x40AE09D: _gfortran_st_read (transfer.c:3069)
==9635==    by 0x80489A9: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF47: finalize_transfer (transfer.c:2962)
==9635==    by 0x40AC0C0: _gfortran_st_read_done (transfer.c:3101)
==9635==    by 0x8048A2A: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF4D: finalize_transfer (transfer.c:2962)
==9635==    by 0x40AC0C0: _gfortran_st_read_done (transfer.c:3101)
==9635==    by 0x8048A2A: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)
==9635== 
==9635== Conditional jump or move depends on uninitialised value(s)
==9635==    at 0x40ABF58: finalize_transfer (transfer.c:2962)
==9635==    by 0x40AC0C0: _gfortran_st_read_done (transfer.c:3101)
==9635==    by 0x8048A2A: MAIN__ (in
/home/hp/gcc/o/gcc/testsuite/gfortran/streamio_1.exe)
==9635==    by 0x8048ABA: main (fmain.c:21)

(-v doesn't yield further details, but I'll attach -v output from valgrind when
streamio_1 is linked static.  Lots of interesting libgfortran-related
information. :)

So, I'll unassign myself from this PR, but will stand by for assistance. 
Jerry?


-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|hp at gcc dot gnu dot org   |unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

------- Comment #7 from hp at gcc dot gnu dot org  2008-12-07 21:51 -------
Created an attachment (id=16847)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16847&action=view)
valgrind -v output from streamio_1 compiled "-O2 -static" on
i686-unknown-linux-gnu (freshly updated F 9)

Ignore the first 100 lines, which I believe are due to glibc bugs (missing
valgrind suppressions for static linking with glibc-2.8). Run valgrind using:
"env LD_LIBRARY_PATH=@copy from libgfortran.log@ valgrind -v ./streamio_1.exe"


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2008-12-07 23:58 -------
This has been seen before and until now I thought it was an artifact of
valgrind and that the Front end is suppose to set some values.  I will see if
we can fix this.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-12-06 19:16:54         |2008-12-07 23:58:31
               date|                            |


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-12-08 02:03 -------
First, thanks for the trace.

Please try this patch.  In the meantime, I need to make sure I have the
backward compatibility with 4.3 runtime OK.  I have one other spot to check in
the code.

Index: transfer.c
===================================================================
--- transfer.c  (revision 142528)
+++ transfer.c  (working copy)
@@ -2141,7 +2141,7 @@ data_transfer_init (st_parameter_dt *dtp
              return;
            }

-         if (dtp->rec >= dtp->u.p.current_unit->maxrec)
+         if (dtp->pos >= dtp->u.p.current_unit->maxrec)
            {
              generate_error (&dtp->common, LIBERROR_BAD_OPTION,
                              "POS=specifier too large");


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

------- Comment #10 from hp at gcc dot gnu dot org  2008-12-08 23:25 -------
(In reply to comment #9)

> Please try this patch.

That did it!  Thanks.

(Haven't checked whether this eliminates the valgrind complaints in the posted
trace, but the FAILs in this PR were fixed.)

brgds, H-P


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2008-12-09 03:20 -------
Subject: Bug 38430

Author: jvdelisle
Date: Tue Dec  9 03:19:09 2008
New Revision: 142575

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142575
Log:
2008-12-08  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR libfortran/38430
        * io/transfer.c (data_transfer_init): Move constraint check for REC=
        and STREAM access into condition for other REC= constraints to
simplify.
        Comment out this constraint to avoid breaking compatibility with 4.3
        until later.  Added a TODO for above comment and this one.
        Fix test for max pos.

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


-- 


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

[Bug fortran/38430] [4.4 Regression]: gfortran.dg/streamio_1.f90, 10, 14, 2, 6 now fails

[hp at gcc dot gnu dot org]

------- Comment #12 from hp at gcc dot gnu dot org  2008-12-09 09:17 -------
.


-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.4.0


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