[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