[Bug c++/24208] C++ front-end can still be sped up

2023-02-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/24208] C++ front-end can still be sped up

2016-01-27 Thread ppalka at gcc dot gnu.org
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&root=gcc&view=rev Log: Low-hanging C++-lexer speedup (PR c++/24208) gcc/cp/ChangeLog:

[Bug c++/24208] C++ front-end can still be sped up

2013-10-02 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208 Paolo Carlini changed: What|Removed |Added CC||tsaunders at mozilla dot com --- Comment

[Bug c++/24208] C++ front-end can still be sped up

2006-11-14 Thread pinskia at gcc dot gnu dot org
--- 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%) gg

[Bug c++/24208] C++ front-end can still be sped up

2006-11-14 Thread pinskia at gcc dot gnu dot org
--- 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%

[Bug c++/24208] C++ front-end can still be sped up

2005-10-09 Thread sabre at nondot dot org
--- 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

[Bug c++/24208] C++ front-end can still be sped up

2005-10-09 Thread pinskia at gcc dot gnu dot org
--- 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 --

[Bug c++/24208] C++ front-end can still be sped up

2005-10-09 Thread pinskia at gcc dot gnu dot org
--- 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

2005-10-04 Thread pinskia at gcc dot gnu dot org
--- 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 ve

[Bug c++/24208] C++ front-end can still be sped up

2005-10-04 Thread sabre at nondot dot org
--- 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=9886&action=view) Large C++ file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208