------- Comment #10 from dberlin at gcc dot gnu dot org 2006-11-07 17:40 ------- Subject: Re: jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes
On 6 Nov 2006 00:43:29 -0000, dave at hiauly1 dot hia dot nrc dot ca <[EMAIL PROTECTED]> wrote: > > > ------- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-06 > 00:43 ------- > Subject: Re: jc1: out of memory allocating 4072 bytes after a total of > 708630224 bytes > > > So this ends up being what i thought. The variables aren't being > > collapsed, but i can't figure out why (IE it can't prove they are the > > same). This causes it to give them separate solution bitmaps, and the > > solutions are very large,and involve thousands of variables, so > > thousands * thousands = a lot of memory. > > It appears that every one of them has its address taken. The code > skips such variables: > > /* We can't eliminate things whose address is taken, or which is > the target of a dereference. */ > if (vi->address_taken || vi->indirect_target) > continue; > > > However, all of these variables should collapse, as they do in the > > earlier functions. > > For the record, I believe we die processing this constructor function: > > ;; Function _GLOBAL__I_0__ZN3gnu3xml8aelfred215XmlParser$InputC1Ev() > (_GLOBAL__I > _0__ZN3gnu3xml8aelfred215XmlParser$InputC1Ev) > > The alias1 files has the following: > > ... > ESCAPED_VARS = &gnu.xml.xpath.AndExpr.class$$.engine > > Collapsing static cycles and doing variable substitution: > > Solving graph: > > Dave > > I agree with your assessment, I will fix it so they all collapse again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29587
