--- 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
--
--- 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
--
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
--- 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
--- 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
--- 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. I
--- 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
--- 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_
--- 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: war
--- 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 a
--- 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 get
--- 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 gfort
--- 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 t
--- 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
--- 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
15 matches
Mail list logo
