[Bug libfortran/34887] New: NIST FM903.f anomaly

[Bug libfortran/34887] New: NIST FM903.f anomaly

[jvdelisle at gcc dot gnu dot org]

We are computing the correct result for test 8 of FM903.f, but one of the
"Correct" answers is truncated.  Both are truncated in 4.2 and my last patch
gives this.

With FM903.f

gfortran:     
                 COMPUTED= 
                          12.34506.78 120.34 506.78 123.40 567.80
                 CORRECT:                        2 CORRECT ANSWERS POSSIBLE
                          12.34506.78 120.34 506.78

                         +12.34506.78 120.34 506.78 123.40 567.80


g77, sun, intel
                 COMPUTED= 
                          12.34506.78 120.34 506.78 123.40 567.80
                 CORRECT:                        2 CORRECT ANSWERS POSSIBLE
                          12.34506.78 120.34 506.78 123.40 567.80

                         +12.34506.78 120.34 506.78 123.40 567.80


-- 
           Summary: NIST FM903.f anomaly
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jvdelisle at gcc dot gnu dot org


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

[tkoenig at gcc dot gnu dot org]

------- Comment #1 from tkoenig at gcc dot gnu dot org  2008-01-20 20:18 -------
Reduced test case:

$ cat bug-4.f
      program main
      write (*,'(3X A, T1, A,/)') 'aa', 'bb'
      end
$ gfortran bug-4.f && ./a.out
bb

$ g77 bug-4.f && ./a.out
bb aa


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2008-01-20 20:18:11
               date|                            |
            Summary|NIST FM903.f anomaly        |reverse tabbing before slash
                   |                            |descriptor (regression vs.
                   |                            |g77)


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

[tkoenig at gcc dot gnu dot org]

------- Comment #2 from tkoenig at gcc dot gnu dot org  2008-01-20 21:39 -------
What about this one-character patch?

Index: transfer.c
===================================================================
--- transfer.c  (revision 131679)
+++ transfer.c  (working copy)
@@ -1308,7 +1308,7 @@ formatted_transfer_scalar (st_parameter_
        case FMT_SLASH:
          consume_data_flag = 0 ;
          dtp->u.p.skips = dtp->u.p.pending_spaces = 0;
-         next_record (dtp, 0);
+         next_record (dtp, 1);
          break;

        case FMT_COLON:


-- 


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

[tkoenig at gcc dot gnu dot org]

------- Comment #3 from tkoenig at gcc dot gnu dot org  2008-01-20 21:40 -------
(currently regtesting)


-- 


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

[tkoenig at gcc dot gnu dot org]

------- Comment #4 from tkoenig at gcc dot gnu dot org  2008-01-20 22:19 -------

> -         next_record (dtp, 0);
> +         next_record (dtp, 1);

This causes a regression in x_slash_1.f .  I'll dig around
some more.


-- 


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

[tkoenig at gcc dot gnu dot org]

------- Comment #5 from tkoenig at gcc dot gnu dot org  2008-01-24 22:09 -------

> This causes a regression in x_slash_1.f .  I'll dig around
> some more.

There's something wrong here (as evidenced in the PR :-)
In next_record_w, we should be following the path starting with
if (done) every time, to get this right.

I'm not 100% sure what

                      length = (int) (max_pos - m);
                      p = salloc_w (dtp->u.p.current_unit->s, &length);  

does when we never write to the memory pointed to by p. Maybe
this is used as an idiom to mark the memory, which may have
been written to earlier, as "dirty".  It's horrible in any case :-)


-- 


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

[jvdelisle at gcc dot gnu dot org]

------- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-01-25 00:53 -------
What it does is stated in the comment.

/* If the farthest position reached is greater than current
   position, adjust the position and set length to pad out
   whats left.  Otherwise just pad whats left.
   (for character array unit) */

IIRC that comment needs to be repeated down below.  The bytes that are
"allocated" have been already written to previously.  We know this from
max_pos.  All this is doing is moving the file position back out the necessary
number of bytes and assuring they get flushed out to disk later.  If we just do
a seek, we may skip over bytes and not write them to disk.  This also assures
that those bytes are marked dirty.

Its really not horrible once you understand it.  I am not convinced the if
(done) is needed at line 2579 though.  Have to think some more.  Maybe try
taking the condition away and see what happens.


-- 


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

[tkoenig at gcc dot gnu dot org]

------- Comment #7 from tkoenig at gcc dot gnu dot org  2008-01-26 08:52 -------
 am not convinced the if
> (done) is needed at line 2579 though.  Have to think some more.  Maybe try
> taking the condition away and see what happens.


I don't think it's needed.  I am currently testing a version without
it, and it fixed the original bug. x_slash_1.f also works.

Currently regression-testing.


-- 


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

[tkoenig at gcc dot gnu dot org]

------- Comment #8 from tkoenig at gcc dot gnu dot org  2008-01-26 15:23 -------
Subject: Bug 34887

Author: tkoenig
Date: Sat Jan 26 15:22:59 2008
New Revision: 131864

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131864
Log:
2008-01-26  Thomas Koenig  <tkoenig@gcc.gnu.org>

        PR libfofortran/34887
        * io/transfer.c (next_record_w): Always move to the farthest
        position when completing the record (also when we are
        processing a slash edit descriptor).

2008-01-26  Thomas Koenig  <tkoenig@gcc.gnu.org>

        PR libfofortran/34887
        * gfortran.dg/x_slash_2.f:  New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/x_slash_2.f
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/transfer.c


-- 


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

[tkoenig at gcc dot gnu dot org]

------- Comment #9 from tkoenig at gcc dot gnu dot org  2008-01-26 15:24 -------
Fixed on trunk.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

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


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