--- Comment #16 from tobi at gcc dot gnu dot org 2007-04-13 15:16 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from tobi at gcc dot gnu dot org 2007-04-13 14:48 ---
Subject: Bug 18937
Author: tobi
Date: Fri Apr 13 14:48:08 2007
New Revision: 123789
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123789
Log:
PR fortran/18937
fortran/
* resolve.c: Include obstack.h and bitma
--- Comment #14 from patchapp at dberlin dot org 2007-03-26 04:41 ---
Subject: Bug number PR 18937
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01650.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #13 from tobi at gcc dot gnu dot org 2007-03-25 20:51 ---
I have a patch which does eveything, except detecting branches to END DOs. I
can't seem to figure out how to do this in a sensible way without introducing a
replacement quadratic bottleneck :-(
--
http://gcc.gnu.
--- Comment #12 from tobi at gcc dot gnu dot org 2007-03-23 22:35 ---
Well, "within the blink of an eye" because I was looking at spaghetti 1000 :-)
But the increase in time is linear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
--- Comment #11 from tobi at gcc dot gnu dot org 2007-03-23 22:27 ---
I've implemented Steven's bitmap idea (see PR18540). spaghetti 9 compiles
within the blink of an eye. Unfortunately, my current patch foregos step four
from resolve_branch, which is necessary to establish validit
--- Comment #10 from tobi at gcc dot gnu dot org 2006-01-26 16:46 ---
I don't know when I will have time for this, so I'm unassigning myself.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from tobi at gcc dot gnu dot org 2006-01-18 21:07 ---
The committed patch fixes only part of the problem, this is still a quadratic
bottleneck.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-18 20:54 ---
Subject: Bug 18937
Author: tobi
Date: Wed Jan 18 20:54:49 2006
New Revision: 109914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109914
Log:
PR fortran/18540
PR fortran/18937
* gfortran.h (BBT_HEADER): Move d
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #7 from tobi at gcc dot gnu dot org 2006-01-09 18:57 ---
Discussion on how to fix this has taken place in PR18540.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-14 22:09
---
*** Bug 18943 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-12
16:19 ---
g77 has the same problem:
$ time g77 spaghetti.f
real0m11.649s
user0m11.516s
sys 0m0.068s
$ ./spaghetti 2 > spaghetti.f
$ time g77 spaghetti.f
real0m50.604s
user0m48.738s
sys
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-11
11:55 ---
The problem in gfc_get_st_label() is easy to solve - just turn st_labels
into a hash table. The problem in resolve.c is more difficult, I need to
think about that a little more...
--
http://gcc.gnu.
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-11
10:40 ---
(In reply to comment #1)
> Actually all of the time is spent in the parser so this is not a middle-end
problem.
You're correct. For example, the C frontend does not exhibit
this behavior:
$ ./spaghetti
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-11
08:49 ---
One more note g77 in 3.3 is faster.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18937
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-11
08:45 ---
Actually all of the time is spent in the parser so this is not a middle-end
problem.
Also note you did you did not disable checking which is enabled by default on
non release branches.
parser
17 matches
Mail list logo
