From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94549 invoked by alias); 14 Jul 2016 20:31:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 94538 invoked by uid 89); 14 Jul 2016 20:31:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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; Thu, 14 Jul 2016 20:31:11 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 00E18F2624; Thu, 14 Jul 2016 20:31:10 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6EKV9u3019490; Thu, 14 Jul 2016 16:31:09 -0400 Subject: Re: [PATCH] Handle undefined extern vars in output_in_order To: Alexander Monakov , Jan Hubicka References: <20160616142524.GA93274@kam.mff.cuni.cz> <20160616152403.GA38925@kam.mff.cuni.cz> <20160616154239.GA416@kam.mff.cuni.cz> Cc: gcc-patches@gcc.gnu.org From: Jeff Law Message-ID: <852ef3a0-9e46-994c-05b4-8f2ab40d27bd@redhat.com> Date: Thu, 14 Jul 2016 20:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00876.txt.bz2 On 06/23/2016 08:45 AM, Alexander Monakov wrote: > Hi, > > I've discovered that this assert in my patch was too restrictive: > > + if (DECL_HAS_VALUE_EXPR_P (pv->decl)) > + { > + gcc_checking_assert (lookup_attribute ("omp declare target link", > + DECL_ATTRIBUTES (pv->decl))); > > Testing for the nvptx target uncovered that there's another case where a > global variable would have a value expr: emutls. Sorry for not spotting it > earlier (but at least the new assert did its job). I think we should always > skip here over decls that have value-exprs, just like hard-reg vars are > skipped. The following patch does that. Is this still OK? > > (bootstrapped/regtested on x86-64) > > Alexander > > * cgraphunit.c (cgraph_order_sort_kind): New entry ORDER_VAR_UNDEF. > (output_in_order): Loop over undefined variables too. Output them > via assemble_undefined_decl. Skip variables that correspond to hard > registers or have value-exprs. > * varpool.c (symbol_table::output_variables): Handle undefined > variables together with defined ones. OK. Thanks for your patience. jeff