From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30693 invoked by alias); 2 Oct 2015 01:15:00 -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 30680 invoked by uid 89); 2 Oct 2015 01:14:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 02 Oct 2015 01:14:57 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id t921EVbq004095; Thu, 1 Oct 2015 20:14:39 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id t921ESt3004088; Thu, 1 Oct 2015 20:14:28 -0500 Date: Fri, 02 Oct 2015 01:15:00 -0000 From: Segher Boessenkool To: Alan Modra Cc: Richard Biener , GCC Patches , David Edelsohn Subject: Re: [PATCH] rs6000: Add "cannot_copy" attribute, use it (PR67788, PR67789) Message-ID: <20151002011424.GA3657@gate.crashing.org> References: <20151001171808.GA30971@gate.crashing.org> <20151002005406.GI32709@bubble.grove.modra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151002005406.GI32709@bubble.grove.modra.org> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00146.txt.bz2 On Fri, Oct 02, 2015 at 10:24:07AM +0930, Alan Modra wrote: > On Thu, Oct 01, 2015 at 12:18:08PM -0500, Segher Boessenkool wrote: > > On Thu, Oct 01, 2015 at 12:14:44PM +0200, Richard Biener wrote: > > > So even if not "easy", can you try? > > > > I did, and after half a day had a big mess and lots of things failing, > > no idea where this was headed, and in the meantime bootstrap still fails > > (on affected targets). > > I had a look too, and while you can revise the load_toc_v4_PIC > patterns to use labels emitted the usual way (eg. as in > i386.c:ix86_init_large_pic_reg) they tend to wander away from the > insn. Yes, and only "bcl 20,31,$+4" avoids the link stack on recent CPUs (bcl 20,31,$+8, which we also use, doesn't). > I think that could be solved, but these labels which aren't > referred to by jump insns get converted to NOTE_INSN_DELETED_LABEL > somewhere, and that leads to further pain. Yes. You need to make the bcl a jump_insn to the label. And then there is yet more pain. Segher