From patchwork Fri Aug 17 21:07:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 959127 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-483893-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="N6HLPKUi"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 41sbQ4083xz9rvt for ; Sat, 18 Aug 2018 07:07:54 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=WfnBWbUVuv7JCY/F2 XherRQswDY/d/oDdcyp0UgNJhHoRtbMBvocqpFjHV5TEymPExxiaIp8+E9cVnDAz hWQZNX2UbnVUQ+aRjt6vBBllcLqH4vGLMTde7w1QKhEz+++7nFVhWyLq35wllpDP fQysWkV4x5owzE3JaD1+PaQS48= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=gw/IYb5duxLOLpfWwz40HKD la1s=; b=N6HLPKUiTDM4thBB3ZXEJVMRqSqvL2ICBy8Z66s6tmq0T73z8I+ojbM hKV8xaij975Ppj7ePOB9ApbD0azH/j6leTNfoVspOfc/2cy03t4IPtJT5vJtrPts rAN9IQk6PvTuaH1QYYUZJDg2M+kGNfrz+yjBoqrQimc5D08pwtXM= Received: (qmail 129384 invoked by alias); 17 Aug 2018 21:07:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 125974 invoked by uid 89); 17 Aug 2018 21:07:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy=sk:dw_at_c, Hx-languages-length:4743, sk:DW_AT_c X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Aug 2018 21:07:45 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 0F31FADE2; Fri, 17 Aug 2018 21:07:43 +0000 (UTC) Date: Fri, 17 Aug 2018 23:07:44 +0200 From: Tom de Vries To: gcc-patches@gcc.gnu.org Cc: Jakub Jelinek , Richard Biener , Cary Coutant , Jason Merrill Subject: [PATCH][debug] Fix handling of vlas in lto Message-ID: <20180817210744.GA15027@delia> References: <20180817100430.GA29582@delia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180817100430.GA29582@delia> User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes I've rewritten the patch to work generically, not just for DW_AT_upper_bound, and to reuse the code already there in add_scalar_info. OK for trunk? Thanks, - Tom [debug] Fix handling of vlas in lto Atm, when running vla-1.c with -O0 -flto, we have: ... FAIL: gcc.dg/guality/vla-1.c -O0 -flto -fuse-linker-plugin \ -fno-fat-lto-objects line 17 sizeof (a) == 6 ... The vla a[i + 1] in f1 is gimplified into: ... f1 (int i) { char a[0:D.1922] [value-expr: *a.0]; char[0:D.1922] * a.0; D.1921 = i + 1; D.1926 = (sizetype) D.1921; a.0 = __builtin_alloca_with_align (D.1926, 8); ... The early debug info for the upper bound of the type of vla a that we stream out is: ... DIE 0: DW_TAG_subrange_type (0x7f85029a90f0) DW_AT_upper_bound: location descriptor: (0x7f85029a9230) DW_OP_GNU_variable_value die -> 0 (0x7f85029a94b0), 0 DIE 0: DW_TAG_variable (0x7f85029a94b0) DW_AT_name: "D.1922" DW_AT_type: die -> 0 (0x7f85029a3d70) DW_AT_artificial: 1 ... and in ltrans we have for that same upper bound: ... DIE 0: DW_TAG_subrange_type (0x7f5183b57d70) DW_AT_upper_bound: die -> 0 (0x7f5183b576e0) DIE 0: DW_TAG_variable (0x7f5183b576e0) DW_AT_name: "D.4278" DW_AT_abstract_origin: die -> label: vla_1.c.6719312a + 193 (0x7f5183b57730) ... where D.4278 has abstract origin D.1922. The D.4278 die has no DW_AT_location, so when evaluting "sizeof (a)" in the debugger, we can't find the information to get the value of D.4278, and the debugger prints "". This patch fixes that by either: - adding DW_AT_location to the referenced variable die, or - instead of using a ref for the upper bound, using an exprloc. When changing gcc.dg/guality/guality.exp to run the usual flto flavours "-fno-use-linker-plugin -flto-partition=none" and "-fuse-linker-plugin -fno-fat-lto-objects" in combination with O0, Og, O1, O2, O3 and Os, this patch fixes all (20) failures in vla-1.c, leaving only: ... No symbol "i" in current context. UNSUPPORTED: gcc.dg/guality/vla-1.c -O3 -flto -fno-use-linker-plugin \ -flto-partition=none line 17 i == 5 'a' has unknown type; cast it to its declared type UNSUPPORTED: gcc.dg/guality/vla-1.c -O3 -flto -fno-use-linker-plugin \ -flto-partition=none line 17 sizeof (a) == 6 ... Bootstrapped and reg-tested on x86_64. 2018-08-17 Tom de Vries * dwarf2out.c (add_scalar_info): Don't add reference to existing die unless the referenced die describes the added property using DW_AT_location or DW_AT_const_value. Fall back to exprloc case. Otherwise, add a DW_AT_location to the referenced die. --- gcc/dwarf2out.c | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index 9ed473088e7..e1dccb42823 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -20598,7 +20598,7 @@ static void add_scalar_info (dw_die_ref die, enum dwarf_attribute attr, tree value, int forms, struct loc_descr_context *context) { - dw_die_ref context_die, decl_die; + dw_die_ref context_die, decl_die = NULL; dw_loc_list_ref list; bool strip_conversions = true; bool placeholder_seen = false; @@ -20675,7 +20675,7 @@ add_scalar_info (dw_die_ref die, enum dwarf_attribute attr, tree value, if (decl != NULL_TREE) { - dw_die_ref decl_die = lookup_decl_die (decl); + decl_die = lookup_decl_die (decl); /* ??? Can this happen, or should the variable have been bound first? Probably it can, since I imagine that we try to create @@ -20684,8 +20684,12 @@ add_scalar_info (dw_die_ref die, enum dwarf_attribute attr, tree value, later parameter. */ if (decl_die != NULL) { - add_AT_die_ref (die, attr, decl_die); - return; + if (get_AT (decl_die, DW_AT_location) + || get_AT (decl_die, DW_AT_const_value)) + { + add_AT_die_ref (die, attr, decl_die); + return; + } } } } @@ -20729,15 +20733,19 @@ add_scalar_info (dw_die_ref die, enum dwarf_attribute attr, tree value, || placeholder_seen) return; - if (current_function_decl == 0) - context_die = comp_unit_die (); - else - context_die = lookup_decl_die (current_function_decl); + if (!decl_die) + { + if (current_function_decl == 0) + context_die = comp_unit_die (); + else + context_die = lookup_decl_die (current_function_decl); + + decl_die = new_die (DW_TAG_variable, context_die, value); + add_AT_flag (decl_die, DW_AT_artificial, 1); + add_type_attribute (decl_die, TREE_TYPE (value), TYPE_QUAL_CONST, false, + context_die); + } - decl_die = new_die (DW_TAG_variable, context_die, value); - add_AT_flag (decl_die, DW_AT_artificial, 1); - add_type_attribute (decl_die, TREE_TYPE (value), TYPE_QUAL_CONST, false, - context_die); add_AT_location_description (decl_die, DW_AT_location, list); add_AT_die_ref (die, attr, decl_die); }