On Fri, Mar 4, 2011 at 3:49 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, Mar 04, 2011 at 03:30:34PM +0100, Richard Guenther wrote: >> On Fri, Mar 4, 2011 at 2:56 PM, Richard Sandiford >> > Jakub confirms that this indeed the intended behaviour, and I haven't >> > seen any problem with the output. >> >> Hm, but isn't it incorrect debug info? I would have expected this >> non-localized var to be the abstract origin of a copy for location >> list purposes. > > I thought we've discussed that on IRC. For -fcompare-debug reasons > the decision on what decl is localized and what goes into > BLOCK_NONLOCALIZED_VARS can't take into account debug stmts (otherwise > there would be -fcompare-debug failures). > Thus, we sometimes decide to have some BLOCK_NONLOCALIZED_VARS vars > referenced in debug stmts. > The way this works is we do normal var-tracking against those, and then > at dwarf2out.c time just pick their locations up. > See e.g. > http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00445.html > for some of the details.
Sure. But then location lists for those variables depend on the function context and cannot be shared for different callers. Am I missing something? Likewise I don't see how they could be shared for multiple inline instances in the same function. Richard. > Jakub >
