[Bug c++/55135] Segfault of gcc on a big file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #30 from Jan Hubicka --- Reconfirmed that we still take ages to build the testcase (early inliner is still running for me) The early inliner issue here is caused by tree-inline removing individual clones one by one. Each time a clone is removed a new clone becomes a root of the clone tree and it takes long time to update all pointers.
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|4.4.5 |4.8.0 Target Milestone|4.8.0 |--- Summary|[4.8 Regression] Segfault |Segfault of gcc on a big |of gcc on a big file|file --- Comment #23 from Richard Biener rguenth at gcc dot gnu.org 2013-03-06 10:47:18 UTC --- PR47344 tracks the regression property of this bug.
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.3 Known to fail||4.7.2, 4.8.0 --- Comment #24 from Steven Bosscher steven at gcc dot gnu.org 2013-03-06 12:09:26 UTC --- (In reply to comment #23) PR47344 tracks the regression property of this bug. ?! This is also a regression from GCC 4.6 (commen #5), how in the world does that qualify as an old regression?
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #25 from Steven Bosscher steven at gcc dot gnu.org 2013-03-06 12:10:31 UTC --- (NB 4.6.3 known to work w.r.t. comment #5, not w.r.t. original bug report)
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #26 from rguenther at suse dot de rguenther at suse dot de 2013-03-06 12:14:03 UTC --- On Wed, 6 Mar 2013, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.3 Known to fail||4.7.2, 4.8.0 --- Comment #24 from Steven Bosscher steven at gcc dot gnu.org 2013-03-06 12:09:26 UTC --- (In reply to comment #23) PR47344 tracks the regression property of this bug. ?! This is also a regression from GCC 4.6 (commen #5), how in the world does that qualify as an old regression? Ah, just because nobody has tried 4.5 doesn't say it isn't a regression in 4.6! (what is a regression in compile-time / memory-usage? technically I'd say if T2 T1 or M2 M1 it's a regression ... welcome to the world of an ever increasing number of open regressions)
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #27 from Richard Biener rguenth at gcc dot gnu.org 2013-03-06 12:16:06 UTC --- Btw, I wouldn't call gcc-4.6.3: 1:39.92 total work ;) Also the reporter says the bug is in 4.4.5 (so we are again turning a bug into a different bug ... :/)
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #28 from Steven Bosscher steven at gcc dot gnu.org 2013-03-06 12:18:01 UTC --- (In reply to comment #22) Posted for discussion here: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00193.html OT: Another trivial speed-up for bitmaps used as regsets (and probably in general) is to look at head-first if head-current is not the element containing the sought bit, and *not* update head-current if head-first is the right element. This speeds up regsets because a common access pattern is to look at sets containing both pseudos and hardregs, and on most targets all hardregs are in head-first. Not updating head-current preserves a pointer to the latest accessed pseudos. I'll implement this idea and come back with some timings.
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #29 from rguenther at suse dot de rguenther at suse dot de 2013-03-06 12:23:21 UTC --- On Wed, 6 Mar 2013, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #28 from Steven Bosscher steven at gcc dot gnu.org 2013-03-06 12:18:01 UTC --- (In reply to comment #22) Posted for discussion here: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00193.html OT: Another trivial speed-up for bitmaps used as regsets (and probably in general) is to look at head-first if head-current is not the element containing the sought bit, and *not* update head-current if head-first is the right element. This speeds up regsets because a common access pattern is to look at sets containing both pseudos and hardregs, and on most targets all hardregs are in head-first. Not updating head-current preserves a pointer to the latest accessed pseudos. I'll implement this idea and come back with some timings. Indeed a nice idea ;) I suppose -current should only be updated if its new distance to head-first is bigger than magic number (and zero is of course an obvious one)
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2012-10-30 00:00:00 |2013-02-28 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2013-02-28 22:49:16 UTC --- I first tried at -O0, only to run into even worse compile time issues, hitting quadratic behavior in the number of EH regions, and having a huge number of them: void LHA::Load();; remove_queued_eh_handlers: # eh regions: 179972 The remove_queued_eh_handlers function is new, I'll attach a patch here after proper testing. With that problem out of the way, the next hurdle is IRA but I'm still trying to figure that one out.
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2013-02-28 23:58:38 UTC --- Created attachment 29557 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29557 Collected hacks to make the test case compile in reasonable time with -O0 Patch does 2 things: - Queue up to-be-removed EH regions, instead of removing them one-by-one. Removing them one at a time results in walking the list of EH regions repeatedly, thus taking O(# of EH regions ** 2) time. - Rewrite init_subregs_of_mode and subroutines to first collect the invalid mode change subregs in sbitmaps, and then converting the final sbitmap to a bitmap. This trades memory for time: the bitmap lookups are also potentially O(# of registers ** 2) and this test case has more than one million registers, many of them with invalid mode changes (to be fixed up by IRA/LRA). Peak memory at -O0 is 4GB. Compile time on a Quad-Core AMD Opteron(tm) Processor 8354 at 2200MHz is 240s, half of it still taken up by IRA+LRA. At -O1 the einline pass is consuming almost all compile time again. - Honza: Can we please have a proper permanent fix for this recurring problem? What's there now just Does Not Work!
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED CC||stevenb.gcc at gmail dot ||com Ever Confirmed|1 |0 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-27 16:20:47 UTC --- I can't reproduce the crash either. I'm not sure if we should keep the PR open as regards compile-time performance issues (or we have already a similar testcase in Bugzilla?) Steven?
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Severity|major |normal
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #6 from benoit.barbot at gmail dot com 2012-10-31 16:31:37 UTC --- I try the same file but on a different computer with a newer version of gcc(gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) with the same problem: g++ buggcc.ii g++: erreur interne du compilateur: Processus arrêté (program cc1plus)
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #7 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-10-31 16:45:43 UTC --- (In reply to comment #6) I try the same file but on a different computer with a newer version of gcc(gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) with the same problem: g++ buggcc.ii g++: erreur interne du compilateur: Processus arrêté (program cc1plus) Make sure you have enough RAM (over 4GB) to compile this testcase. Check your dmesg for the OOM-killer.
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #1 from benoit.barbot at gmail dot com 2012-10-30 10:28:22 UTC --- The file is too big to be attached. Here is a URL where you can find it: http://www.lsv.ens-cachan.fr/~barbot/cosmos/files/buggcc.ii
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2012-10-30 10:39:43 UTC --- Please try newer version of GCC.
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-10-30 CC|benoit.barbot at gmail dot | |com | Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-10-30 11:48:23 UTC --- And if you can still reproduce, please attach here a preprocessed file of manageable size. Thanks.
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #4 from benoit.barbot at gmail dot com 2012-10-30 13:29:04 UTC --- When i remove line in the file the segfault disappear. The size of the file seams to trigger the segfault.
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-10-30 14:03:47 UTC --- I can't reproduce the crash, but what's interesting are the compile times (without optimization just -c buggcc.ii): clang++: 26.95 total gcc-4.6.3: 1:39.92 total gcc-4.7.2: 6:04.07 total gcc-4.8 : 7:16.84 total
