This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Copying a DECL_SIZE for inlining multiple times (was: [testcase] C tree inlining ICE)


On Oct 17, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> I'm not sure I have enough context here, but I should point out that the
> C++ front end does some relatively nasty things with SAVE_EXPRs to deal
> with these kinds of problems.

Such as cp_unsave?  I'm not sure when cp_unsave kicks in, and I see
the C front-end doesn't have anything equivalent, but still, it
doesn't seem like it would be necessary.  All we really need is to
guarantee that a single SAVE_EXPR is mapped to a single SAVE_EXPR, no
matter how many occurrences of the SAVE_EXPR there are in the tree,
and no matter how many times it occurs in a tree.  Ideally, we should
never attempt to map a pointer to a node more than once, but we
currently do, and this is what caused the problem.

Bottom line, my question is whether copying the DECL_SIZE and
DECL_SIZE_UNIT of a declaration is necessary in remap_decl, or whether
it would be enough to leave it up to walk_tree to implicitly do it.  I
found that just removing those calls to walk_tree would fix the
problem at hand, but I didn't go as far as running the whole
bootstrap&test cycle with this change.  I'll give it a try today, and
see whether I get any regressions.  It might be a good thing to not
only remove the redundant copies, but also get an already-mapped item
to be mapped to an error mark, instead of silently duplicating it.

> On the other hand, your changes look plausible.

Is this an ok to install, for now?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]