This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/14179] [3.3/3.4/3.5 Regression] out of memory
- From: "mmitchel at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Mar 2004 23:08:46 -0000
- Subject: [Bug c++/14179] [3.3/3.4/3.5 Regression] out of memory
- References: <20040217171044.14179.debora.j.estey@lmco.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From mmitchel at gcc dot gnu dot org 2004-03-08 23:08 -------
I've investigated this problem.
To some extent, this problem is inevitable. In the old days, we used to output
assembly code for a global array element-by-element as we saw it. That's not
what we want to do: we want to store up the array so that we can optimize loads
from fixed indices, etc.
However, we do waste a ton of memory. We allocate a separate INTEGER_CST for
each occurrence of the same integer constant, even though there are only a few
of them. We allocate an entirely new list of constants when we refactor the
brace-enclosed form (essentially adding braces that C++ says you can omit). We
allocate an integer constant for every possible index into the array, which has
8 million entries.
We should be representing the initializer with a structure like this:
struct init_group {
struct init_group *next;
tree designator; /* The designator for the first element in the array. */
tree elts[];
};
rather than a linked-list per element. That would be far more efficient for
large arrays and a win even for small arrays.
None of this is going to get fixed until 3.5, however.
--
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.4.0 |3.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179