From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 601 invoked by alias); 21 Jul 2006 16:57:33 -0000 Received: (qmail 483 invoked by uid 48); 21 Jul 2006 16:57:25 -0000 Date: Fri, 21 Jul 2006 16:57:00 -0000 Message-ID: <20060721165725.482.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/23551] dwarf records for inlines appear incomplete In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "drow at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-07/txt/msg01650.txt.bz2 List-Id: ------- Comment #10 from drow at gcc dot gnu dot org 2006-07-21 16:57 ------- (In reply to comment #9) > Case 1: > There is no location info for the parameter x because it has been optimized > away. Change the variable x in main to y to avoid ambiguity, compile with > -fdump-tree-all, and look at the t27 and t29 dumps. In the t27 dump, the > variable x is there and assigned to. In the t29 dump, the variable x is there, > but no longer assigned to. Since it is no longer assigned to, we never > allocate space for it, and hence no location attribute can be emitted. t29 is > the copyrename dump file. If I compile with -fno-tree-copyrename, then I do > get a location attribute for the parameter x in the inlined copy of foo. I > don't think there is any bug here, but if there is, it would be in the tree > copyrename pass, because there is no longer any useful parameter x when it is > done. For the record, I encountered this problem today also (formals with no location information). Not a single argument had a location. Adding -fno-tree-copyrename fixed one (of about seven). In this case the variables are all used, mostly in non-trivial ways. My testcase was eval.c from GDB; the function evaluate_struct_tuple is inlined and debugging into it is quite hard. I'm working on improving this in GDB, but I can't improve where the compiler gives me nothing to work with. We already know that there are many similar problems in the tree optimizers; I'm just adding a data point. -- drow at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|0000-00-00 00:00:00 |2006-07-21 16:57:25 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551