This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] live analysis on local static functions
- From: Richard Henderson <rth at redhat dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, Jan Hubicka <jh at suse dot cz>, gcc mailing list <gcc at gcc dot gnu dot org>, Diego Novillo <dnovillo at redhat dot com>
- Date: Tue, 14 Oct 2003 10:59:59 -0700
- Subject: Re: [tree-ssa] live analysis on local static functions
- References: <200310141734.h9EHYnGx012804@speedy.slc.redhat.com> <1066153643.10504.2025.camel@p4>
On Tue, Oct 14, 2003 at 01:47:20PM -0400, Andrew MacLeod wrote:
> nope. both are 0. Oh wait, yeah. the one in the BIND_EXPR does ($7). It
> points to the one we are using in a_1. (the $9 value)
So there's a bug in inlining somewhere. One of the following
must be true:
(1) All inline function instances share the same local statics,
and so remapping the value in the BIND_EXPR is wrong, or
(2) All inline function instances have their own instances of
local statics and so not remapping the value in the body of
the function is wrong (which leads to the a_1 use).
I seem to recall that (1) is correct, since that doesn't change
semantics depending on how inlining does or does not occur.
I can see that something must be done for debugging, since you
want to refer back to the origin from the inlined instance. No
idea how this interacts with the rest of the code...