[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-22 07:40:26 UTC --- Fixed for current trunk, maybe a dup of PR54332
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-22 07:43:30 UTC --- Fixed for current trunk, maybe a dup of PR54332
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2012-08-22 08:59:04 UTC --- No question, this was a dup. *** This bug has been marked as a duplicate of bug 54332 ***
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-15 09:57:13 UTC --- seems like it is triggered by unrolling, using gfortran -O2 -funroll-loops -ffree-form -D__LIBINT hfx_contraction_methods.F is enough. A bt at the first point where memory seems to go up is: #1 0x007176de in df_scan_verify () at ../../gcc/gcc/df-scan.c:4540 #2 0x00706245 in df_verify () at ../../gcc/gcc/df-core.c:1645 #3 df_analyze () at ../../gcc/gcc/df-core.c:1206 #4 0x008a211b in iv_analysis_loop_init (loop=0x7f4b0ece63b8) at ../../gcc/gcc/loop-iv.c:299 #5 0x008a56ba in get_simple_loop_desc (loop=0x7f4b0ece63b8) at ../../gcc/gcc/loop-iv.c:2973 #6 0x008a8c70 in decide_peel_once_rolling (flags=2) at ../../gcc/gcc/loop-unroll.c:337 #7 peel_loops_completely (flags=2) at ../../gcc/gcc/loop-unroll.c:248 #8 unroll_and_peel_loops (flags=2) at ../../gcc/gcc/loop-unroll.c:164 #9 0x0089cc98 in rtl_unroll_and_peel_loops () at ../../gcc/gcc/loop-init.c:370
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-15 10:05:26 UTC --- Well, that's ENABLE_CHECKING code. Are you sure 4.7 built with --enable-checking=yes does not exhibit this behavior?
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-15 10:59:38 UTC --- (In reply to comment #2) Well, that's ENABLE_CHECKING code. Are you sure 4.7 built with --enable-checking=yes does not exhibit this behavior? I'm pretty sure this was not observed 3 weeks ago on trunk. Just to make sure, I'm doing a new trunk build with --enable-checking=no.
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-15 11:37:51 UTC --- (In reply to comment #2) Well, that's ENABLE_CHECKING code. Are you sure 4.7 built with --enable-checking=yes does not exhibit this behavior? it looks like --enable-checking is key. --enable-checking=no leads to about 1Gb, while --enable-checking=yes leads to about 10Gb mem usage.
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-16 05:29:46 UTC --- 4.7 configured with --enable-checking=yes also needs 1.0Gb. for a checking enable compiler, time went from 25s with 4.7 to 1m27s with 4.8
