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%
Created attachment 9570 [details] old program that hangs gfortran
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.
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.
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.
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.
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.
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
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.
I agree with Steve's comment that a maximal number of errors should be allowed, after which the compiler should bail out.
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 ()
Mine. Will regtest when i get to a machine with TeX installed.
untake it since Brooks was faster in testing it. See http://gcc.gnu.org/ml/fortran/2006-11/msg00221.html that added -fmax-errors
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.
Since this isn't a regression, the fix won't be backported to 4.1; thus, I'm closing this as fixed.