From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11691 invoked by alias); 15 Sep 2009 13:45:31 -0000 Received: (qmail 11473 invoked by uid 48); 15 Sep 2009 13:45:05 -0000 Date: Tue, 15 Sep 2009 13:45:00 -0000 Message-ID: <20090915134505.11472.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/41353] VTA missed-debug issues In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg01360.txt.bz2 ------- 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