From patchwork Fri Apr 24 20:52:29 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 464415 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 6EDCA140134 for ; Sat, 25 Apr 2015 06:52:41 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass reason="1024-bit key; unprotected key" header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=jtQ4LUZp; dkim-adsp=none (unprotected policy); dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=wB8Z+v9yhdnDjan6AzTBh9PBCxzH29DNpzhFbMzY/ao5aF Y6PMrf/ZAWGYcmu8XJ1jwg3dTxQluusqpIgHeYVV5HpjlgrODdnYHHiMDV9fmBbB AKde5EY57RYdnbj5Ak9WTzJ78RC7I/LfeGf5aKavCMXLaivPbTH3Cd3sg2tuQ= 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 :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=OO3Ftuf/YjRGb9pJHDj28Sx4ma4=; b=jtQ4LUZpAN8jbZcnqUcY 9Vizb5g3nETcBZX9UyHWJzzg9R6txTqyqOiOhHD/vVqoQSWOXrbl5CozFKbdpz4N 7eUxDK3KtiXjx1O/K/O+Mc83EwiAbTLZbsoacsFlx7ubs/84eTQincOP1qV/jz8X Ct4Y3c9D3xnMhD6EJZhrZhc= Received: (qmail 52022 invoked by alias); 24 Apr 2015 20:52:34 -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 52010 invoked by uid 89); 24 Apr 2015 20:52:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 24 Apr 2015 20:52:33 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3OKqUx3010110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 24 Apr 2015 16:52:31 -0400 Received: from reynosa.quesejoda.com (vpn-48-200.rdu2.redhat.com [10.10.48.200]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3OKqT11023513; Fri, 24 Apr 2015 16:52:30 -0400 Message-ID: <553AAD0D.5040206@redhat.com> Date: Fri, 24 Apr 2015 13:52:29 -0700 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Richard Henderson , gcc-patches Subject: [debug-early] fix problem with C_TYPE_INCOMPLETE_VARS and TYPE_VFIELD overloading In the debug-early work we call dwarf2out early from rest_of_decl_compilation. Dwarf2out, via gen_struct_or_union_type_die(), will eventually look at TYPE_VFIELD, which is currently being overloaded by the C front-end to keep incomplete variables. Nobody should be looking at the type too in depth if it's incomplete, but in this case, the type has just been laid out (layout_decl) so it's considered complete, just as we're about to iterate through C_TYPE_INCOMPLETE_VARS and fix things up. To fix my dwarf problem, I've just cached C_TYPE_INCOMPLETE_VARS and immediately clear it, as it was going to be cleared after anyhow. Attached is what I'm committing to the branch, but ideally y'all^Wyall front-end folks should use some language specific node. Nothing was obvious in tree-core.h, as most front-end specific things are flags (booleans), so I've left this as an exercise to the front-end groupie. That being said, if you violently oppose this solution, I'd be more than happy to entertain another (hopefully simple) approach. Aldy p.s. I wonder how many things are being overloaded by the front-end that are being looked at by dwarf2out incorrectly. Well, nothing that triggers a gdb regression.... commit 0fa38f203619300ed1ea92418bc6dbabd1115ac9 Author: Aldy Hernandez Date: Fri Apr 24 13:41:36 2015 -0700 Cache and clear C_TYPE_INCOMPLETE_VARS before iterating through its members to avoid an overload problem within dwarf2out. diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c index 846e13b..688c055 100644 --- a/gcc/c/c-decl.c +++ b/gcc/c/c-decl.c @@ -7827,10 +7827,18 @@ finish_struct (location_t loc, tree t, tree fieldlist, tree attributes, } /* If this structure or union completes the type of any previous - variable declaration, lay it out and output its rtl. */ - for (x = C_TYPE_INCOMPLETE_VARS (TYPE_MAIN_VARIANT (t)); - x; - x = TREE_CHAIN (x)) + variable declaration, lay it out and output its rtl. + + Note: C_TYPE_INCOMPLETE_VARS overloads TYPE_VFIELD which is used + in dwarf2out via rest_of_decl_compilation below and means + something totally different. Since we will be clearing + C_TYPE_INCOMPLETE_VARS shortly after we iterate through them, + clear it ahead of time and avoid problems in dwarf2out. Ideally, + C_TYPE_INCOMPLETE_VARS should use some language specific + node. */ + tree incomplete_vars = C_TYPE_INCOMPLETE_VARS (TYPE_MAIN_VARIANT (t)); + C_TYPE_INCOMPLETE_VARS (TYPE_MAIN_VARIANT (t)) = 0; + for (x = incomplete_vars; x; x = TREE_CHAIN (x)) { tree decl = TREE_VALUE (x); if (TREE_CODE (TREE_TYPE (decl)) == ARRAY_TYPE) @@ -7843,7 +7851,6 @@ finish_struct (location_t loc, tree t, tree fieldlist, tree attributes, rest_of_decl_compilation (decl, toplevel, 0); } } - C_TYPE_INCOMPLETE_VARS (TYPE_MAIN_VARIANT (t)) = 0; /* Update type location to the one of the definition, instead of e.g. a forward declaration. */