https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
--- Comment #7 from Eric Gallager ---
(In reply to xiaoyuanbo from comment #6)
> total root
What did you mean by this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
xiaoyuanbo changed:
What|Removed |Added
CC||xiaoyuanbo at yeah dot net
--- Comment #6 fr
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-18 10:46 ---
But not on the same source, but different one (insn-recog.c grew because of
that change).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
--- Comment #4 from aj at gcc dot gnu dot org 2009-02-18 10:17 ---
Increasing ulimit from 100 to 110 (10 %!) did not help, increasing it
to 120 helped.
So, we have now hit quite some increase of memory usage with just this single
commit and not just a few bytes...
--
ht
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-18 08:54 ---
Yeah, with ulimit you can always pick some limit almost any change might go
over. As a bug should be only considered if memory usage increases a lot,
daily tiny increases and decreases in memory usage aren't a bug.
--- Comment #2 from ubizjak at gmail dot com 2009-02-18 07:15 ---
The commit you are referring to just hit the nail on the road and gets over
your memory threshold. The blockage insertion is enabled only for
-fno-omit-frame-pointer.
Even if we revert this patch (very unlikely, since it
--- Comment #1 from aj at gcc dot gnu dot org 2009-02-17 21:10 ---
Created an attachment (id=17316)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17316&action=view)
insn-recog.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
