------- Comment #4 from jakub at gcc dot gnu dot org 2009-09-15 13:45 -------
Created an attachment (id=18585)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18585&action=view)
gcc45-pr41353.patch
I've looked briefly at the problem with correct var location notes followed by
(nil) ones and I believe the problem is that we don't order MO_VAL_USE notes
before MO_VAL_LOC ones, which I believe we have to. This patch fixes this
testcase, will do a full bootstrap/regtest of it now.
Another thing, unrelated to this, are TREE_STATIC var definitions, without
DECL_RTL_SET_P. Consider say (again, -gdwarf-4 -O2):
int i = 1, j, k = 1;
int
foo (void)
{
int i1 = 2 * i;
int i2 = 2 * i;
int k1 = 2 * k;
int k2 = 2 * k;
return j;
}
Here i2 has correct debug info (and with this patch also i1), but k1 and k2
don't have any location. The difference is that i is the first global object,
where notice_global_symbol calls DECL_RTL for it, while k already isn't the
first one and DECL_RTL is done only when varpool is finalized. The important
question now is, is it safe to do DECL_RTL if not already set from
expand_debug_expr, at least for some TREE_STATIC VAR_DECLs? Is the DECL_RTL
avoidance just to avoid the expensive computing of the name mangling? If it
won't make a -fcompare-debug difference, I think we should make_decl_rtl,
otherwise perhaps have some way to defer this for later (create a MEM with
something inside it that would later during debug info emission (when all the
varpool stuff is finalized) we'd need to double check that the decl has been
actually emitted so that vars aren't referenced just in .debug_info/.debug_loc
and nowhere else.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353
