This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Merge results as of 2003-05-06
- From: Jason Merrill <jason at redhat dot com>
- To: law at redhat dot com
- Cc: Diego Novillo <dnovillo at redhat dot com>, gcc at gcc dot gnu dot org, Jason Merrill <jason at redhat dot com>
- Date: Thu, 08 May 2003 02:53:57 -0400
- Subject: Re: [tree-ssa] Merge results as of 2003-05-06
- References: <200305080629.h486Ta0o012946@speedy.slc.redhat.com>
On Thu, 08 May 2003 00:29:36 -0600, law@redhat.com wrote:
> In message <wvl3cjq6jm2.fsf@prospero.boston.redhat.com>, Jason Merrill writes:
> >> FAIL: g++.dg/eh/cleanup1.C (test for excess errors)
> >>
> >> This causes the compiler to enter an infinite loop in
> >> function.c:preserve_temp_slots. The linked list temp_slots
> >> is circular. The program compiles fine with
> >> -fdisable-simple.
> >
> >I don't think it's circular, I think it's just unimaginably huge. I think
> >we aren't currently dealing with temp slots properly in GENERIC, so they
> >build up instead of being reused. Investigating.
> It could well be that they're just insanely large -- let's say I've spent
> a little time getting familiar with cleanup1.C. It's a major source of
> headaches for the tree-ssa optimizers due to it's insane nesting of
> its TRY_CATCH/TRY_FINALLY blocks.
Actually, now that I think about it we can't really free temp slots,
because in GIMPLE all temporaries look like automatic variables in the
outer block of the function. In this testcase, we don't see a single temp
that we don't want to keep forever.
A simple solution may just be to disable all the temp_slots management code
when we're using the tree optimizers. A better solution would be to fix
the temp_slots data structure so that we don't keep slogging through the
whole list when we're only interested in slots from a particular level.
My expression temps patch should help to cut down on the number of temps we
have to deal with; it cuts the number in this testcase by 75%.
Jason