[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- 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
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
-- 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
--- 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
--- 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
--- 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. 0x00442fd4 in gfc_match_common () at ../../../src/gcc-4.3/gcc/fortran/match.c:2349 2349 while (tail-common_next) (gdb) bt #0 0x00442fd4 in gfc_match_common () at ../../../src/gcc-4.3/gcc/fortran/match.c:2349 #1 0x0044ecc0 in match_word (str=0xa47600 common, subr=0x442e26 gfc_match_common, old_locus=0x7fd75220) at ../../../src/gcc-4.3/gcc/fortran/parse.c:65 #2 0x0044f164 in decode_statement () at ../../../src/gcc-4.3/gcc/fortran/parse.c:193 #3 0x004502ef in next_fixed () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- 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
--- 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
--- 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) 2285tail = 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
--- 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 21 | 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
--- 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
--- 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
--- 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
--- 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=9570action=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
--- 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|-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
--- 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
