This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
- From: "dnovillo at google dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 21 Aug 2012 18:31:51 +0000
- Subject: [Bug fortran/54332] [4.8 Regression] 481.wrf in SPEC CPU 2006 takes > 10GB memory to compile
- Auto-submitted: auto-generated
- References: <bug-54332-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
--- Comment #18 from dnovillo at google dot com <dnovillo at google dot com> 2012-08-21 18:31:51 UTC ---
OK, I think this is the hunk that's causing grief:
diff --git a/gcc/df-scan.c b/gcc/df-scan.c
index 39f444f..35100d1 100644
--- a/gcc/df-scan.c
+++ b/gcc/df-scan.c
@@ -4392,7 +4392,6 @@ df_bb_verify (basic_block bb)
if (!INSN_P (insn))
continue;
df_insn_refs_verify (&collection_rec, bb, insn, true);
- df_free_collection_rec (&collection_rec);
}
/* Do the artificial defs and uses. */
I remember that I ran into this during the VEC conversion
(http://gcc.gnu.org/ml/gcc/2012-05/msg00271.html) and after some
discussion I ended up convincing myself that taking it out was harmless.
Clearly, I was wrong.
I've hooked gdb to the running f951 and it's stuck in df_bb_verify().
Odd that this has not triggered anywhere else.