--- Comment #17 from jakub at gcc dot gnu dot org 2010-03-23 06:48 ---
But clearly it is not var-tracking that eats all the memory, instead it is the
scheduler, and it happens also with -g0, and doesn't happen with
-fno-schedule-insns -fno-schedule-insns2. So, please open a separate
--- Comment #16 from wilson at gcc dot gnu dot org 2010-03-23 00:58 ---
The testcase checked into mainline is causing kernel panics on my debian
testing ia64-linux machine when I run the gcc testsuite. The kernel panic is
coming from the out-of-memory killer, when it runs out of
--- Comment #14 from jakub at gcc dot gnu dot org 2010-03-18 20:15 ---
Subject: Bug 43058
Author: jakub
Date: Thu Mar 18 20:15:05 2010
New Revision: 157547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157547
Log:
PR debug/43058
* var-tracking.c
--- Comment #15 from jakub at gcc dot gnu dot org 2010-03-18 20:30 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-17 10:58 ---
Reduced testcase at -g -O2 on x86_64 grows during var-tracking get_max_uid ()
from ~ 22000 to over a 100. Adding ten X4's instead of 1 of course eats
even more memory.
extern void *f1 (void *, void *, void *);
--- Comment #13 from jakub at gcc dot gnu dot org 2010-03-17 15:05 ---
Created an attachment (id=20130)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20130action=view)
gcc45-pr43058.patch
So far untested fix. This just optimizes handling of optimized out variables
which are known
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-03-12 12:06
---
re-confirmed with r157384.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-05 15:19 ---
I was hoping PR43176 caching patch would actually fix this too, but apparently
that's not the case, because the problem here is not that we are emitting
useless notes, but that the notes for hundreds of `a' variables
--- Comment #9 from jakub at gcc dot gnu dot org 2010-02-24 18:25 ---
It is vt_emit_notes that eats all the memory, not vt_find_locations, and the
memory doesn't go into the hash tables, but for rtx allocation.
I've printed ggc statistics on vt_emit_notes entry and after I left it eat
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-19 11:55 ---
The recent patch to add PARAM_MAX_VARTRACK_SIZE didn't fix this. We still
top out beyond what my machine with 3GB ram and 1GB swap can handle.
GCC 4.4.3 tops at 620MB
GCC 4.5 with -fno-var-tracking-assignments
--- Comment #7 from mmitchel at gcc dot gnu dot org 2010-02-17 16:56
---
I think this is a critical problem. If var-tracking is causing factor-of-N
increases in memory usage, then we need an algorithmic change that prevents
that, even if that means inferior debug information. We're
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-15 16:57 ---
The following doesn't make too much sense:
static bool
cgraph_mark_inline_edge (struct cgraph_edge *e, bool update_original,
VEC (cgraph_edge_p, heap) **new_edges)
{
...
/* Now update
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-13 19:06 ---
Created an attachment (id=19859)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19859action=view)
testcase from snd
Testcase from snd.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-13 19:12 ---
Indeed. After IPA-inline we have:
Init_libxg/4659(4659) @0x7fffef076138 availability:available 65 time, 10
benefit (112338 after inlining) 37 size, 1 benefit (89974 after inlining)
needed reachable body
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-13 19:25 ---
limit += limit * PARAM_VALUE (PARAM_LARGE_FUNCTION_GROWTH) / 100;
/* Check the size after inlining against the function limits. But allow
the function to shrink if it went over the limits by forced
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-13 19:38 ---
With that we get the much more sane
Deciding on functions called once:
Considering define_strings size 840.
Called once from Init_libxg 37 insns.
Inlined into Init_libxg which now has 876 size for a net change
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-13 19:56 ---
Of course we'll blow up during var-tracking from within define_functions
anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
17 matches
Mail list logo
