From patchwork Tue Jun 17 16:50:56 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 360687 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 0161B140077 for ; Wed, 18 Jun 2014 02:51:10 +1000 (EST) 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=Ehut/BRIXmQRm/lHD TLX+mea671VtIG2Q/GaXU444WsvI1ks5GH4M0h8SnJLukgAl6OiGZSOqCNFBS5TB dcna2pkFeIp3uLidxyJ6l2LWYBcKbMvFh9l64aVg3paABWJNqxSkRdusI2f4yRRc sG5F2TYPZGRFgo9hWnQbYJunWw= 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=J7R4ivEB7B2Xk2eXw3eAfU+ tw6U=; b=JLK4MobX1niwsUJpMJLHxaHnUIYTGrrWI1tmoXYcaGRbtry46IWA5Ue U8ls2Q1/vPhciaePWABhpBY5xanG4XY6NZPRcRQuZoeDUe7xKkvdAVDqTRzunnFH VmlkCOF9p+kIiRMNKW8uL3JZRSkWPTiXOwGR2odhAJqRcMCu3KcM= Received: (qmail 2360 invoked by alias); 17 Jun 2014 16:51:03 -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 2349 invoked by uid 89); 17 Jun 2014 16:51:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 17 Jun 2014 16:51:00 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 87307540D96; Tue, 17 Jun 2014 18:50:56 +0200 (CEST) Date: Tue, 17 Jun 2014 18:50:56 +0200 From: Jan Hubicka To: David Edelsohn Cc: Jan Hubicka , GCC Patches Subject: Re: Another AIX Bootstrap failure Message-ID: <20140617165056.GB28053@kam.mff.cuni.cz> References: <20140616043557.GA6530@kam.mff.cuni.cz> <20140616220638.GA12228@kam.mff.cuni.cz> <20140617034447.GA28053@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) > > To avoid using PLT and GOT when the unit refers to the symbol and we know > > that interposition does not matter. > > I am not certain if the linker is creating the PLT stub code because > it wants to allow interpolation or because it cannot see a definition > of the function and wants to allow for some other shared library to > provide the definition at runtime. OK, but the definition appears in the same file.. > > > Why branch to a non-global (static) symbol > > b ._ZN14__gnu_parallel9_SettingsC1Ev.localalias.0 > > leads to PLT stub here and why branching to such symbols seems to work otherwise? > > Branching to non-global (static) symbol, even an alias, is working > here. The weak function seems to be the problem. > > > The failing branch is > >> b ._ZN14__gnu_parallel9_SettingsC1Ev.localalias.0 > > so the call to static construction seems to have happened correctly but we can > > not get right the call from the constructor to static function (that is an alias > > of a global symbol) > > The linker appears to not want to resolve the weak function. If I > change ._ZN14__gnu_parallel9_SettingsC1Ev to lglobl, it works. If I > change the static constructor to call the weak function directly, > avoiding the alias, it shows the same failure mode. > > I don't know what code generation looked like before. Was GCC > generating calls to weak functions within the same file? Yes, this is how you implement COMDAT functions, right? I looked at rs6000 call expansion and it does not seem to care about visibility properties (just about direct wrt indirect call). One problem I can think of is a scenario where linked unify calls comdat functoins in between units somehow forgetting about the aliases, but this function seems to not be shared. disable generation of the local aliases completely. I do not see much of difference in the actual codegen with this... I will check older GCC Honza > > Thanks, David Index: symtab.c =================================================================== --- symtab.c (revision 211693) +++ symtab.c (working copy) @@ -1327,10 +1327,8 @@ (void *)&new_node, true); if (new_node) return new_node; -#ifndef ASM_OUTPUT_DEF /* If aliases aren't supported by the assembler, fail. */ return NULL; -#endif /* Otherwise create a new one. */ new_decl = copy_node (node->decl);