[Bug libfortran/38772] New: r143102 breaks xplor-nih

[Bug libfortran/38772] New: r143102 breaks xplor-nih

[howarth at nitro dot med dot uc dot edu]

The change in revision 143102...

uthor: jvdelisle
Date: Mon Jan  5 22:55:15 2009
New Revision: 143102

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143102
Log:
2009-01-05  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR libfortran/38735
        * io/unit.c (get_internal_unit): Set default BLANK= status to NULL for
        internal units.

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

...causes 22 testsuite regressions in xplor-nih. The change breaks the routines
in xplor-nih that parse xplor script files. Regressing r143102 from current gcc
trunk eliminates the xplor-nih failures.


-- 
           Summary: r143102 breaks xplor-nih
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2009-01-09 01:47 -------
Without a testcase, it is difficult to determine if the problem is
with gfortran or a bug in your application.

>From Section 9.2.2.1, Internal File Properties, 

 (8) On input, blanks are treated in the same way as for an external file
     opened with a BLANK= specifier having the value NULL and records are
     padded with blanks if necessary (9.4.4.4.2).

>From Section 9.3.4.6, BLANK= Specifier in the OPEN statement,

   The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK=
   specifier is permitted only for a file being connected for formatted
   input/output.  If NULL is specified, all blank characters in numeric
   formatted input fields on the specified unit are ignored, except that
   a field of all blanks has a value of zero.  If ZERO is specified, all
   blanks other than leading blanks are treated as zeros. If this specifier
   is omitted, the default value is NULL.


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #2 from howarth at nitro dot med dot uc dot edu  2009-01-09 02:14 -------
I've contacted the author of xplor-nih as the parsing code is pretty complex
legacy fortran. However I would note that they build this code with the a
variety of commercial fortran compilers.

PowerPC darwin xlf 8.1
i386 Linux ifc version: 9.1.051
ia64 Linux  Intel fortran version 10.1.012
x86_64 Linux Intel Fortran version 10.1.012


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[jvdelisle at gcc dot gnu dot org]

------- Comment #3 from jvdelisle at gcc dot gnu dot org  2009-01-09 03:00 -------
I am looking into it. Thanks for the report.


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2009-01-09 03:32 -------
I have reviewed our library code to see if we are handling BLANK=status
correctly. AFAICT we are doing this right.  I was concerned with your report
because I thought maybe we were getting a side effect from the patch, but I see
nothing at the moment.

I am going to check g77 behavior.  Maybe something legacy happening here.


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2009-01-09 04:03 -------
g77, ifort, and gfortran 4.4 all pass this test case which should print
nothing.

c     { dg-do run }
c     PR38097 I/O with blanks in exponent fails; BN edit descriptor
c     Test case derived from reporter.
      character(11)  :: a = ' 2.  3 e+ 3'
      character(11)  :: b = ' 2.003 e+ 3'
      character(11)  :: c = ' 2.002 e+1 '
      real :: f

      f = 0.0
      read (a,'(BZ,E11.0)') f
      if (f .ne. 2003.0) print *,11, f
      f = 0.0
      read (a,'(BN,E11.0)') f
      if (f .ne. 2300.0) print *,14, f
      f = 0.0
      read (b,'(BN,E11.0)') f
      if (f .ne. 2003.0) print *, 17,f
      f = 0.0
      read (c,'(E11.0)') f
      if (f .ne. 20.020) print *, f
      f = 0.0
      read (c,'(BZ,E11.0)') f
      if (f .ne. 2.002e10) print *, f

      end
c     end of program

gfortran 4.3 Fails this.  What do the other compilers do?


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #6 from howarth at nitro dot med dot uc dot edu  2009-01-09 16:28 -------
Jerry,
    Your test program doesn't produce an error under ifort 10.1.015. I'll try
to pinpoint the exact failure this weekend. At the moment, the problem appears
to be in the code that reads the reflections data. This is in the format...

 INDEx    0   2   0  Fobs  4171.8999

The xplor-nih gets confused parsing these fields and then doesn't recognize the
END statement closing the reflections data section of the xplor.inp script.
I'll
try some print statements to figure out where the parsing is deviating with the
recent libgfortran change.


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #7 from howarth at nitro dot med dot uc dot edu  2009-01-10 00:10 -------
Jerry,
    It appears that the numerical values for all of the refinement table
entries are properly read. However for some reason the next line with the 'end'
statement gets lost. I have to duplicate this 'end' statement or it isn't
parsed.


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #8 from howarth at nitro dot med dot uc dot edu  2009-01-10 19:57 -------
Jerry,
    If I use the following patch to xplor-nih....

--- xrmani.f.org        2009-01-09 17:48:46.000000000 -0500
+++ xrmani.f    2009-01-10 14:29:42.000000000 -0500
@@ -363,6 +363,7 @@
       END IF
       END DO
 C
+      write(6,*) 'before if ', H, K, L, WD
       IF (.NOT.COND) THEN
       CALL SAVEWD
       OK=.TRUE.
@@ -375,7 +376,9 @@
       CALL XAB(FOBS(REFLCT),AFOBS,PFOBS*RAD)
 C============================================================
       ELSE              
+      write(6,*) 'before chkend ', H, K, L, WD
       CALL CHKEND('REFLection>',DONE)
+      write(6,*) 'after chkend ', H, K, L, WD
       END IF
       END IF
       IF (.NOT. (DONE)) goto 137

I find that without r14310, I get...

 before if            4           0           7 INDEX                           

 before if            4           1           7 END                             

 before chkend            4           1           7 END                         

 after chkend            4           1           7 END                          

whereas with r143102, I get...

 before if            4           0           7 INDEX                           

 before if            4           1           7 FWINDOW                         

 before chkend            4           1           7 FWINDOW                     

 %REFLection-ERR: unrecognized command:
    fwindow 
    ^^^^^^^
 after chkend            4           1           7 FWINDOW                      


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2009-01-11 16:43 -------
Reviewing code carefully, I found the following.  I can not confirm this is the
problem, but removing this portion of code does not cause a regression in our
current testsuite.  This snippit was left over from before we updated the
handling of the various "status" flags.  When I applied the r143102 patch to
change the default BLANK= for internal units, this condition was enabled.

@@ -504,22 +495,7 @@ next_char (st_parameter_dt *dtp, char **

   (*w)--;

-  if (c != ' ')
-    return c;
-  if (dtp->u.p.blank_status != BLANK_UNSPECIFIED)
-    return ' ';  /* return a blank to signal a null */ 
-
-  /* At this point, the rest of the field has to be trailing blanks */
-
-  while (*w > 0)
-    {
-      if (*q++ != ' ')
-       return '?';
-      (*w)--;
-    }
-
-  *p = q;
-  return '\0';
+  return c;
 }




-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #10 from howarth at nitro dot med dot uc dot edu  2009-01-11 23:00 -------
The patch in comment 9 doesn't solve the issue with xplor-nih.


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #11 from howarth at nitro dot med dot uc dot edu  2009-01-13 00:52 -------
Created an attachment (id=17081)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17081&action=view)
test program demonstrating missing error condition


-- 


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

[Bug libfortran/38772] r143102 breaks xplor-nih

[howarth at nitro dot med dot uc dot edu]

------- Comment #12 from howarth at nitro dot med dot uc dot edu  2009-01-13 00:55 -------
The attached badread,f test program produces...

 F

...when attempting to read a float with...

      READ(TEMP,'(F20.0)',ERR=9999) R

from....

      TEMP='                END'

when run against the libgfortran prior to r143102. After r143102, the
libgfortran results
in the output of....

 T

which is means that we aren't properly handling error conditions in the
floating point read routines now.


-- 


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

[Bug libfortran/38772] r143102 breaks error checking on floating point reads

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2009-01-13 03:44 -------
Great work Jack.  Now we have a test case to work with.


-- 

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|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-13 03:44:53
               date|                            |


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

[Bug libfortran/38772] r143102 breaks error checking on floating point reads

[jvdelisle at gcc dot gnu dot org]

------- Comment #14 from jvdelisle at gcc dot gnu dot org  2009-01-13 04:14 -------
The problem is in read.c.  In reading floats we are not catching invalid
exponent characters.  The BN patch just revealed this bug that has been there
all along.

The string can be just about anything with an 'e' followed by at least one
character, including such things as 'ej' or 'e    k  '.

Incidentally, Daniel's read float patch fixes this.  If any one is brave
enough, we could just commit his patch.  Otherwise I will band aid this one,
hopefully shortly.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code


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

[Bug libfortran/38772] r143102 breaks error checking on floating point reads

[jvdelisle at gcc dot gnu dot org]

------- Comment #15 from jvdelisle at gcc dot gnu dot org  2009-01-13 04:36 -------
Here is a patch.  If the character is not a digit or a blank, we exit the loop
and skip the test for not a digit.  DUH!  (first part of patch is just an
indentation fix)

Index: read.c
===================================================================
--- read.c      (revision 143139)
+++ read.c      (working copy)
@@ -972,14 +972,14 @@ read_f (st_parameter_dt *dtp, const fnod
       while (w > 0)
         {
           if (*p != ' ')
-         goto bad_float;
+           goto bad_float;
           p++;
           w--;
         }
     }    
   else  /* BZ or BN status is enabled */
     {
-      while (w > 0 && (isdigit (*p) || *p == ' '))
+      while (w > 0)
         {
           if (*p == ' ')
             {


-- 


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

[Bug libfortran/38772] r143102 breaks error checking on floating point reads

[howarth at nitro dot med dot uc dot edu]

------- Comment #16 from howarth at nitro dot med dot uc dot edu  2009-01-13 05:06 -------
Jerry,
    While that eliminated the failure in the xtarget.inp testcase for
xplor-nih, it also increased the number of test case failures from 13 to 72 out
of 133 tests. I'll test Daniel's patch to see if it allows all of xplor-nih's
testcases to pass.


-- 


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

[Bug libfortran/38772] r143102 breaks error checking on floating point reads

[howarth at nitro dot med dot uc dot edu]

------- Comment #17 from howarth at nitro dot med dot uc dot edu  2009-01-13 05:31 -------
I'll do a fresh bootstrap with the proposed patch tomorrow. We may have a
separate regression that appeared since I last checked the full xplor-nih
testsuite. Basically, the following difference is appearing in output of half
of the testcases....

@@ -264,8 +264,8 @@
  X-PLOR>energy end 
  --------------- cycle=     1
--------------------------------------------------
  | Etotal =236.279    grad(E)=14.482     E(BOND)=41.209     E(ANGL)=122.157   
|
- | E(DIHE)=0.000      E(IMPR)=48.529     E(VDW )=18.932     E(ELEC)=0.000     
|
- | E(COUP)=5.453                                                              
|
+ | E(DIHE)=0.000      E(IMPR)=48.529     E(VDW )=18.932     E(ELEC)=0.000      
+ | E(COUP)=5.453                                                               
 
-------------------------------------------------------------------------------
  X-PLOR> 
  X-PLOR>coup  print threshold=1.0 class phi end 

somehow we are losing the trailing | character in the output.


-- 


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

[Bug libfortran/38772] r143102 breaks error checking on floating point reads

[jvdelisle at gcc dot gnu dot org]

------- Comment #18 from jvdelisle at gcc dot gnu dot org  2009-01-13 05:40 -------
Subject: Bug 38772

Author: jvdelisle
Date: Tue Jan 13 05:40:36 2009
New Revision: 143327

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

        PR libfortran/38772
        * io/read.c (read_f): Clean up loop conditions for BZ/BN,
        allowing proper digit testing. White space fix.

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


-- 


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

[Bug libfortran/38772] r143102 breaks error checking on floating point reads

[jvdelisle at gcc dot gnu dot org]

------- Comment #19 from jvdelisle at gcc dot gnu dot org  2009-01-13 05:53 -------
Subject: Bug 38772

Author: jvdelisle
Date: Tue Jan 13 05:53:07 2009
New Revision: 143328

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

        PR libfortran/38772
        * gfortran.dg/fmt_bz_bn_err.f: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/fmt_bz_bn_err.f
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/38772] r143102 reveals missed error checking on floating point reads

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2009-01-13 05:57 -------
Thanks for help Jack.  The patch committed does fix the test case you provided.
 Please double check with xplor-nih and if fixed as expected we can close this
PR.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|r143102 breaks error        |r143102 reveals missed error
                   |checking on floating point  |checking on floating point
                   |reads                       |reads


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

[Bug libfortran/38772] r143102 reveals missed error checking on floating point reads

[jvdelisle at gcc dot gnu dot org]

------- Comment #21 from jvdelisle at gcc dot gnu dot org  2009-01-13 06:07 -------
Reply to comments 16 and 17 which I did not see before my commit.  Please make
sure the original r143102 is in place when you apply latest patch.  It does
seem bothersome that the xplor-nih is so sensitive.  It is largely due to
depending on error conditions.

I don't think we want to jump to Daniels patch until we understand what's wrong
here.

Regardless, I will need a reduced test case to go further.


-- 


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

[Bug libfortran/38772] r143102 reveals missed error checking on floating point reads

[howarth at nitro dot med dot uc dot edu]

------- Comment #22 from howarth at nitro dot med dot uc dot edu  2009-01-14 01:23 -------
Jerry,
    The patch you committed solves the problems exposed with the xtarget.inp
xplor testcase. There are a large number of other failures with and without
this patch that are unrelated. I will try to testcase the case. FYI, I wouldn't
really blame xplor-nih. It just happens to be very sensitive to breakage in
libgfortran.


-- 


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

[Bug libfortran/38772] r143102 reveals missed error checking on floating point reads

[jvdelisle at gcc dot gnu dot org]

------- Comment #23 from jvdelisle at gcc dot gnu dot org  2009-01-14 03:05 -------
Closing


-- 

jvdelisle at gcc dot gnu dot org changed:

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


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