From patchwork Fri May 30 21:02:19 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 354344 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 3E4861400D8 for ; Sat, 31 May 2014 07:02:58 +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=ovRgswCR1MUfAZbKA 1Y5KT4cEhwKb5f7Y0K9z3mVoo0IQAaKVAwobq9HuKeInvf/oMaPZOWy84TDJEk8T Kgmm0e+qQBTOzvoOA8CBmLCi7W48LmP2FB1lfZm7pjtJxKuWEmNzbCBEF0sJuXVK aKdY6EqSOlZXDpossC8g0kq1jk= 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=5g8ALXHYxTGuUSMTdXCMH/6 DHSk=; b=IxC/+I0FPz49YJAzUawkzTTv3QJQRGXgAOrcBAkdmIWkJQfE5nRRgeX FPaNCZewGpWVC1QYkWGWtnpZcOyKmORsUIU/l48sNwlwnxrLr2eizWmxZVSgOl62 bKABPf4uYCPffZNJcnh/YUqLbTRwkkAjeGTJMU88XmS5/lTVZLl8= Received: (qmail 15931 invoked by alias); 30 May 2014 21:02:26 -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 15853 invoked by uid 89); 30 May 2014 21:02:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL, BAYES_50, KAM_STOCKGEN, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD autolearn=no 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; Fri, 30 May 2014 21:02:23 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 451DF541C91; Fri, 30 May 2014 23:02:19 +0200 (CEST) Date: Fri, 30 May 2014 23:02:19 +0200 From: Jan Hubicka To: David Edelsohn Cc: Jan Hubicka , GCC Patches , Richard Henderson , ramrad01@arm.com, Richard Sandiford Subject: Re: ipa-visibility TLC 2/n Message-ID: <20140530210219.GE17544@kam.mff.cuni.cz> References: <20140528223103.GB15880@kam.mff.cuni.cz> <20140528231723.GA31990@kam.mff.cuni.cz> <87bnuh9fdo.fsf@talisman.default> <20140529171214.GB32218@kam.mff.cuni.cz> <877g53ag1p.fsf@talisman.default> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) > Honza, > > For example g++.dg/abi/vcall1.C fails at a call in a "localalias" > function, which jumps to a bad location: > > > (gdb) up > #1 0x100004c0 in B::B() [clone .localalias.2] () > (gdb) x/16i $pc-32 > 0x100004a0 <_ZN1BC2Ev+156>: add r10,r10,r8 > 0x100004a4 <_ZN1BC2Ev+160>: mr r3,r10 > 0x100004a8 <_ZN1BC2Ev+164>: stw r2,20(r1) > 0x100004ac <_ZN1BC2Ev+168>: lwz r10,0(r9) > 0x100004b0 <_ZN1BC2Ev+172>: lwz r11,8(r9) > 0x100004b4 <_ZN1BC2Ev+176>: mtctr r10 > 0x100004b8 <_ZN1BC2Ev.localalias.2+180>: lwz r2,4(r9) > 0x100004bc <_ZN1BC2Ev.localalias.2+184>: bctrl > => 0x100004c0 <_ZN1BC2Ev.localalias.2+188>: lwz r2,20(r1) > 0x100004c4 <_ZN1BC2Ev.localalias.2+192>: addi r1,r31,64 > 0x100004c8 <_ZN1BC2Ev.localalias.2+196>: lwz r0,8(r1) > 0x100004cc <_ZN1BC2Ev.localalias.2+200>: mtlr r0 > 0x100004d0 <_ZN1BC2Ev.localalias.2+204>: lwz r31,-4(r1) > 0x100004d4 <_ZN1BC2Ev.localalias.2+208>: blr I suppose this is the problem Richard mentioned - the offsets are not computed by DECL_RTL callback but by place_block. > >>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point? > >>> It looked at face value like you'd need a recursive call to place_block_symbol > >>> on the target before the copy. > >> > >> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL > >> calculation time. But you are right - it is done by validize_mem that > >> is not done by DECL_RTL. Shall I just call it on target first? > > > > Yeah, sounds like calling place_block_symbol would be safer. I will test: Honza > > > > IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends > > tended to create placeholder decls that for whatever reason ended up with > > an initial DECL_RTL, then changed the properties of the decl later once > > more information was known. (This was all many years ago.) > > > > Thanks, > > Richard Index: varasm.c =================================================================== --- varasm.c (revision 211096) +++ varasm.c (working copy) @@ -7094,6 +7094,7 @@ if (snode->alias) { rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl); + place_block_symbol (symbol); SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target); return; }