This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
- From: "aldot at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Nov 2006 19:14:56 -0000
- Subject: [Bug fortran/23538] gfortran hangs on old cray fortran 66 program
- References: <bug-23538-10129@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla 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