https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #15 from Patrick Palka ---
Author: ppalka
Date: Fri Apr 8 20:17:10 2016
New Revision: 234837
URL: https://gcc.gnu.org/viewcvs?rev=234837&root=gcc&view=rev
Log:
Fix PR c++/70590 (error: location references block not in block tree)
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #14 from Patrick Palka ---
trunk is now at
Execution times (seconds)
phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 1%) wall
1287 kB ( 1%) ggc
phase parsing : 1.28 (100%) usr 0.20 (100%) sys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #13 from Patrick Palka ---
Author: ppalka
Date: Thu Apr 7 16:12:05 2016
New Revision: 234810
URL: https://gcc.gnu.org/viewcvs?rev=234810&root=gcc&view=rev
Log:
Avoid needless unsharing during constexpr evaluation (PR c++/70452)
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #12 from Patrick Palka ---
Turns out that a single line of code is responsible for the 50MB increase in
memory usage relative to 4.9, and that's the call to unshare_expr in
cxx_eval_call_expression:
/* Associate the binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #11 from Patrick Palka ---
gcc 5 shows:
Execution times (seconds)
phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
1311 kB ( 0%) ggc
phase parsing : 2.10 (100%) usr 0.28 (100%) sys 2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #10 from Patrick Palka ---
Author: ppalka
Date: Tue Apr 5 16:40:00 2016
New Revision: 234753
URL: https://gcc.gnu.org/viewcvs?rev=234753&root=gcc&view=rev
Log:
Fix PR c++/70452 (regression in C++ parsing performance)
gcc/cp/ChangeL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #9 from Patrick Palka ---
Author: ppalka
Date: Tue Apr 5 01:20:00 2016
New Revision: 234732
URL: https://gcc.gnu.org/viewcvs?rev=234732&root=gcc&view=rev
Log:
Remove class cache_map and use ggc hash_maps instead (PR c++/70452)
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #8 from Patrick Palka ---
So with the patch instead of making ~200k total copies of the same fn (one for
each recursive call) we only make ~15 total copies (the maximum recursion depth
of the function).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #7 from Patrick Palka ---
Created attachment 38155
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38155&action=edit
patch that reuses the function copies
I attached a small patch (not commented yet) that reduces the runtime (of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #5 from Jakub Jelinek ---
Indeed, started with r217664.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
--- Comment #2 from Richard Biener ---
Hashtable lookups are from location/block remapping done. I _think_ that if
all the copy_body stuff we do for constexpr evaluation would just "drop"
locations for the copy we'd still be fine constexpr wise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
Target Milestone|---
16 matches
Mail list logo
