[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-10-18 Thread rguenth at gcc dot gnu dot org
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-18 09:18 --- Subject: Bug 25878 Author: rguenth Date: Wed Oct 18 09:18:07 2006 New Revision: 117852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117852 Log: 2006-10-18 Richard Guenther <[EMAIL PROTECTED]>

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-02-21 Thread rguenth at gcc dot gnu dot org
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-02-21 11:11 --- Worst offenders are (--disable-checking mainline) cfg cleanup : 2.30 ( 3%) usr 0.00 ( 0%) sys 2.36 ( 3%) wall 1474 kB ( 0%) ggc integration : 5.99 ( 7%) usr 0.29 (11%) sys 6.28 (

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-01-20 Thread steven at gcc dot gnu dot org
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfir

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-01-20 Thread pinskia at gcc dot gnu dot org
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-20 15:57 --- Patch which might help: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00881.html It is not a complete patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-01-20 Thread pinskia at gcc dot gnu dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-20 15:55 --- The other thing which might help here is trying to find more functions which can have nothrow on them which should help compile time. I had a patch which did this at the tree level but never finished it. -- htt

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-01-20 Thread rguenth at gcc dot gnu dot org
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-01-20 15:53 --- And we can hope that the SSA inliner will do better on the temporaries, but I guess the resulting CFG will be unchanged. Penaltizing try/finally in estimate_num_insn_1 instead of declaring them "/* Containers have n

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-01-20 Thread rguenth at gcc dot gnu dot org
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-20 15:50 --- At .ssa we have for the posted fragment the following loads of basic blocks and exception objects: : D.68636_176 = &this_1->iso639_1; D.68641_177 = operator[] (D.68636_176, &D.68639); : this_230 = (struct bas

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-01-20 Thread pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-20 15:48 --- This is all caused by C++ and temporary variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-01-20 Thread pinskia at gcc dot gnu dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-20 15:37 --- This is all due to recursive inlining IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-01-20 Thread rguenth at gcc dot gnu dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-20 15:26 --- Basically, the initialization sequence expands to a sequence of (.03.gimple): __comp_ctor (&D.68628); try { __comp_ctor (&D.68629, &"ab"[0], &D.68628);

[Bug c++/25878] Excessive memory and compile-time with std::map init sequence

2006-01-20 Thread rguenth at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-20 15:23 --- Created an attachment (id=10688) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10688&action=view) testcase Preprocessed testcase, preprocessed with gcc 4.1 on a SuSE 10.1 beta x86_64. I minimized it for topfo