From patchwork Thu Jul 9 09:52:28 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 493352 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 EF3F4140773 for ; Thu, 9 Jul 2015 19:52:41 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=ccY8hKRx; 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:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=V5LBplu4KqkzEhfjv Hv0qpuncMZxkGsAYu6z1ece1SRbsWybrN7N1D1F+aW7idsQwVUEVq7aw0Ocz/RaP 6UiVANV94qL+NjaAMW9prPyDlNvnsuB9Md4JQrDVC1CsdhoPRtct14dRkGDMtEGk Ex29rQxvaPNP1LF8O7wCcfrWHY= 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=w06PjA4AFAn8JG6ZqxxzQZu rnt8=; b=ccY8hKRxLA5kIf5tgH0Yj+h7nqUp9oXasS2snxVnSqGHtUKoRlCYPS7 J2W9NTxny1KzZf99MxEvpw6XJt+Y22cpx2gtnnbzHjzal/Gcrpy3o+/pdUZXAjLi 3m25+h0qW0rcs2FxDHswa0tYo31ntFTTy2pEotfHarPGm8py9nao= Received: (qmail 24590 invoked by alias); 9 Jul 2015 09:52:33 -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 24578 invoked by uid 89); 9 Jul 2015 09:52:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f179.google.com Received: from mail-pd0-f179.google.com (HELO mail-pd0-f179.google.com) (209.85.192.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 09 Jul 2015 09:52:31 +0000 Received: by pdjr16 with SMTP id r16so1465747pdj.3 for ; Thu, 09 Jul 2015 02:52:29 -0700 (PDT) X-Received: by 10.66.165.67 with SMTP id yw3mr29606094pab.95.1436435549789; Thu, 09 Jul 2015 02:52:29 -0700 (PDT) Received: from gnu-tools-1.localdomain (c-24-7-26-57.hsd1.ca.comcast.net. [24.7.26.57]) by smtp.gmail.com with ESMTPSA id e9sm5355394pdk.7.2015.07.09.02.52.28 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 02:52:29 -0700 (PDT) Received: by gnu-tools-1.localdomain (Postfix, from userid 1000) id 19B361C1B88; Thu, 9 Jul 2015 02:52:28 -0700 (PDT) Date: Thu, 9 Jul 2015 02:52:28 -0700 From: "H.J. Lu" To: Richard Biener Cc: GCC Patches Subject: Re: [PATCH] Limit alignment on error_mark_node variable Message-ID: <20150709095228.GA3414@gmail.com> References: <20150708153211.GA14935@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes On Thu, Jul 09, 2015 at 10:16:38AM +0200, Richard Biener wrote: > On Wed, Jul 8, 2015 at 5:32 PM, H.J. Lu wrote: > > There is no need to try different alignment on variable of > > error_mark_node. > > > > OK for trunk if there is no regression? > > Can't we avoid calling align_variable on error_mark_node type decls > completely? That is, punt earlier when we try to emit it. > How about this? OK for trunk? H.J. --- There is no need to analyze error_mark_node type decls. gcc/ PR target/66810 * varpool.cvarpool.c (varpool_node::analyze): Skip error_mark_node type decls. gcc/testsuite/ PR target/66810 * gcc.target/i386/pr66810.c: New test. --- gcc/testsuite/gcc.target/i386/pr66810.c | 10 ++++++++++ gcc/varpool.c | 29 +++++++++++++++++------------ 2 files changed, 27 insertions(+), 12 deletions(-) create mode 100644 gcc/testsuite/gcc.target/i386/pr66810.c diff --git a/gcc/testsuite/gcc.target/i386/pr66810.c b/gcc/testsuite/gcc.target/i386/pr66810.c new file mode 100644 index 0000000..4778b37 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/pr66810.c @@ -0,0 +1,10 @@ +/* { dg-do compile { target ia32 } } */ +/* { dg-options "-mno-sse -mno-mmx -miamcu" } */ + +int vv; + +void +i (void) +{ + static int a[vv]; /* { dg-error "storage size" } */ +} diff --git a/gcc/varpool.c b/gcc/varpool.c index 10fa93c..f7c4d46 100644 --- a/gcc/varpool.c +++ b/gcc/varpool.c @@ -514,20 +514,25 @@ varpool_node::get_availability (void) void varpool_node::analyze (void) { - /* When reading back varpool at LTO time, we re-construct the queue in order - to have "needed" list right by inserting all needed nodes into varpool. - We however don't want to re-analyze already analyzed nodes. */ - if (!analyzed) + /* Skip error_mark_node type decls. */ + if (TREE_TYPE (decl) != error_mark_node) { - gcc_assert (!in_lto_p || symtab->function_flags_ready); - /* Compute the alignment early so function body expanders are - already informed about increased alignment. */ - align_variable (decl, 0); + /* When reading back varpool at LTO time, we re-construct the + queue in order to have "needed" list right by inserting all + needed nodes into varpool. We however don't want to re-analyze + already analyzed nodes. */ + if (!analyzed) + { + gcc_assert (!in_lto_p || symtab->function_flags_ready); + /* Compute the alignment early so function body expanders are + already informed about increased alignment. */ + align_variable (decl, 0); + } + if (alias) + resolve_alias (varpool_node::get (alias_target)); + else if (DECL_INITIAL (decl)) + record_references_in_initializer (decl, analyzed); } - if (alias) - resolve_alias (varpool_node::get (alias_target)); - else if (DECL_INITIAL (decl)) - record_references_in_initializer (decl, analyzed); analyzed = true; }