[Bug fortran/23538] New: gfortran hangs on old cray fortran 66 program

[Bug fortran/23538] New: gfortran hangs on old cray fortran 66 program

[dir at lanl dot gov]

gfortan generates hundreds of error on this program then hangs - never to return

[dranta:~/tests/gfortran-D] dir% gfortran -o d2ds d2ds.f
 In file d2ds.f:88

      common/ioinfo/jprint,isqsh,ni                                     
                   1
Warning: Named COMMON block 'ioinfo' at (1) shall be of the same size
 In file d2ds.f:308

...
...




Error: END DO statement expected at (1)
 In file d2ds.f:1718

      subroutine stravg                                                 
     1
Error: Unclassifiable statement at (1)
^C
[dranta:~/tests/gfortran-D] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ./configure --prefix=/Users/dir/gfortran --enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050823 (experimental)
[dranta:~/tests/gfortran-D] dir%

-- 
           Summary: gfortran hangs on old cray fortran 66 program
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dir at lanl dot gov
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-apple-darwin7.9.0


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[dir at lanl dot gov]

------- Additional Comments From dir at lanl dot gov  2005-08-23 21:03 -------
Created an attachment (id=9570)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9570&action=view)
old program that hangs gfortran


-- 


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[kargl at gcc dot gnu dot org]

------- Additional Comments From kargl at gcc dot gnu dot org  2005-08-23 21:18 -------
Confirmed.

gfortran's error reporting and recovery mechanism appears to lead
to hopeless confusion within the scanner/parser whereby it gets
stuck in an infinite loop.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-08-23 21:18:45
               date|                            |


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[kargl at gcc dot gnu dot org]

------- Additional Comments From kargl at gcc dot gnu dot org  2005-08-23 21:38 -------
Can you compile this code with any modern compiler?  I used
fsplit to split the code into a set of files that contains
exactly one subprogram per file.  Of the 54 *.f files that I
get from fsplit, only 25 of those files can be compiled by
g77.  Oddly, gfortran can compile 28 of the 54 files.

-- 


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[dir at lanl dot gov]

------- Additional Comments From dir at lanl dot gov  2005-08-24 12:56 -------
I got a simular program to compile and run with lahey fortran by changing the
all the * in the format statements to ' and the encode and decode statements to
character read and write statements. I ran this through gfortran ,just, to get
an estimate of how much work it would be to get it running again.

-- 


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[kargl at gcc dot gnu dot org]

------- Additional Comments From kargl at gcc dot gnu dot org  2005-08-24 17:54 -------
Changing the * in the format statements and the encode/decode statements
may help prevent gfortran from getting stuck, but there are several other
nonstandard statements in the code.

To deal with gfortran getting stuck, I think the simplest solution is to
introduce a -ferror-count=N option where gfortran will die with a fatal
error after N error messages have been emitted.  This, of course, only
papers over the problem, but redesigning gfortran's error handling/reporting
is going to be a really big effort.

-- 


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[dir at lanl dot gov]

------- Additional Comments From dir at lanl dot gov  2005-08-24 20:46 -------
Most of the other non-standard elements are considered extensions by Lahey.

Looking at the error output - I think that one "simple ?" change would clear up
much of the trouble. If the gfortran is processing a routine and it hits a error
on an 'end' statement and that 'end' is followed by a 'subroutine' or 'function'
declaration, reset things so that gfortran is done processing errors in the last
routine and start processing the new routine. It is really weird to see a
correct subroutine declaration statement error.

-- 


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[tkoenig at gcc dot gnu dot org]

------- Comment #7 from tkoenig at gcc dot gnu dot org  2005-11-02 21:17 -------
g77 gets confused by the errors, then bails out:

$ g77 d2ds.f
$ g77 d2ds.f 2>&1 | tail
              2
Argument #4 of `maxval' is one type at (2) but is some other type at (1) [info
-f g77 M GLOBALS]
d2ds.f:831: warning:
         call maxval (0,0,sig,eps,ijk,valmax,locval,slab)
              1
d2ds.f:1159: (continued):
         call maxval (1,0,sig,eps,ijk,valmax,locval,slab)
              2
Argument #5 of `maxval' is one type at (2) but is some other type at (1) [info
-f g77 M GLOBALS]
d2ds.f:795: confused by earlier errors, bailing out


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |19292
              nThis|                            |


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2006-01-10 02:46 -------
0x0004ae5c in gfc_match_common () at
/Users/pinskia/src/gcc/alias/gcc/gcc/fortran/match.c:2284
2284              while (tail->common_next)
(gdb) 
2285                tail = tail->common_next;


tail and tail->common_next is the same now, which means we get an infinite
loop.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |compile-time-hog


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[fxcoudert at gcc dot gnu dot org]

------- Comment #9 from fxcoudert at gcc dot gnu dot org  2006-06-04 10:18 -------
I agree with Steve's comment that a maximal number of errors should be allowed,
after which the compiler should bail out.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
OtherBugsDependingO|19292                       |
              nThis|                            |
           Keywords|                            |diagnostic
   Last reconfirmed|2005-08-23 21:18:45         |2006-06-04 10:18:54
               date|                            |


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[aldot at gcc dot gnu dot org]

------- Comment #10 from aldot at gcc dot gnu dot org  2006-11-06 19:14 -------
Should there be a default (I currently default to 100) for -ferror-count?

I did choose to add one single check into gfc_warning_check, so we don't
immediately bail out if the error count did exceed the given limit. Is this
enough or is it better to instrument all of the error code to instantaneously
bail if the limit is reached?

For the testcase, trunk currently ICE like so, fwiw:

Error: END DO statement expected at (1)
d2ds.f:1718:

      subroutine stravg                                                 
     1
Error: Unclassifiable statement at (1)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000442fd4 in gfc_match_common ()
    at ../../../src/gcc-4.3/gcc/fortran/match.c:2349
2349              while (tail->common_next)
(gdb) bt
#0  0x0000000000442fd4 in gfc_match_common ()
    at ../../../src/gcc-4.3/gcc/fortran/match.c:2349
#1  0x000000000044ecc0 in match_word (str=0xa47600 "common", 
    subr=0x442e26 <gfc_match_common>, old_locus=0x7fffffd75220)
    at ../../../src/gcc-4.3/gcc/fortran/parse.c:65
#2  0x000000000044f164 in decode_statement ()
    at ../../../src/gcc-4.3/gcc/fortran/parse.c:193
#3  0x00000000004502ef in next_fixed ()


-- 


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[aldot at gcc dot gnu dot org]

------- Comment #11 from aldot at gcc dot gnu dot org  2006-11-06 19:41 -------
Mine.

Will regtest when i get to a machine with TeX installed.


-- 

aldot at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldot at gcc dot gnu dot org
         AssignedTo|unassigned at gcc dot gnu   |aldot at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-06-04 10:18:54         |2006-11-06 19:41:39
               date|                            |


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[aldot at gcc dot gnu dot org]

------- Comment #12 from aldot at gcc dot gnu dot org  2006-11-10 17:34 -------
untake it since Brooks was faster in testing it.

See http://gcc.gnu.org/ml/fortran/2006-11/msg00221.html
that added -fmax-errors


-- 

aldot at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|aldot 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=23538

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[brooks at gcc dot gnu dot org]

-- 

brooks at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |brooks at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-11-06 19:41:39         |2007-03-05 18:57:17
               date|                            |


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[brooks at gcc dot gnu dot org]

------- Comment #13 from brooks at gcc dot gnu dot org  2007-03-05 20:20 -------
As of now, -fmax-errors has been backported to 4.2; it was committed to trunk
some months ago.  This at least masks this bug.


-- 


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

[Bug fortran/23538] gfortran hangs on old cray fortran 66 program

[brooks at gcc dot gnu dot org]

------- Comment #14 from brooks at gcc dot gnu dot org  2007-03-09 22:21 -------
Since this isn't a regression, the fix won't be backported to 4.1; thus, I'm
closing this as fixed.


-- 

brooks at gcc dot gnu dot org changed:

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


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