[Bug c++/24208] C++ front-end can still be sped up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- The testcase no longer works, even after unincluding. There have been improvements to the operand scanner, so let's close it as fixed.
[Bug c++/24208] C++ front-end can still be sped up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208 --- Comment #9 from Patrick Palka --- Author: ppalka Date: Thu Jan 28 01:06:29 2016 New Revision: 232912 URL: https://gcc.gnu.org/viewcvs?rev=232912=gcc=rev Log: Low-hanging C++-lexer speedup (PR c++/24208) gcc/cp/ChangeLog: PR c++/24208 * parser.c (LEXER_DEBUGGING_ENABLED_P): New macro. (cp_lexer_debugging_p): Use it. (cp_lexer_start_debugging): Likewise. (cp_lexer_stop_debugging): Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/24208] C++ front-end can still be sped up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||tsaunders at mozilla dot com --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 58575 has been marked as a duplicate of this bug. ***
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-15 04:46 --- In 4.2.0 on i686-linux-gnu this is much better: parser: 1.99 (31%) usr 0.28 (28%) sys 2.42 (25%) wall 43674 kB (49%) ggc name lookup : 0.48 ( 7%) usr 0.37 (37%) sys 1.51 (16%) wall 5041 kB ( 6%) ggc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-15 04:48 --- Note, I am not going to close this bug just yet because this testcase produces some weird -O2 timing results for 4.2.0: tree operand scan : 11.29 (27%) usr 0.51 (22%) sys 13.09 (25%) wall 9015 kB ( 4%) ggc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-09 18:39 --- Confirmed. The middle-end problems are almost all in reload.c. For the profile, everything is just spread all around. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-09 18:48 --- I think this is just a problem of templates, lots of them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-09 18:48:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #5 from sabre at nondot dot org 2005-10-09 22:02 --- Some updates: the -ftime-report problems were a local problem with apple's gcc, now fixed. This testcase has some templates (e.g. the match stuff), but mostly it is just big branchy compiler code :), not atypical of many C++ programs. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #1 from sabre at nondot dot org 2005-10-05 00:03 --- Created an attachment (id=9886) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9886action=view) Large C++ file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
[Bug c++/24208] C++ front-end can still be sped up
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-05 00:08 --- (In reply to comment #0) On a somewhat scary note, compiling without -ftime-report speeds up the compilation from 0:11.95 to 0:04.39. This leads me to believe that the -ftime-report numbers can't be trusted very much. This is because Darwin's timing functions are slow. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||compile-time-hog Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
