From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104436 invoked by alias); 22 Jan 2019 00:30:43 -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 104109 invoked by uid 89); 22 Jan 2019 00:30:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=unavailable version=3.3.2 spammy=H*RU:209.85.214.194, Hx-spam-relays-external:209.85.214.194, HX-HELO:sk:mail-pl X-HELO: mail-pl1-f194.google.com Received: from mail-pl1-f194.google.com (HELO mail-pl1-f194.google.com) (209.85.214.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Jan 2019 00:30:04 +0000 Received: by mail-pl1-f194.google.com with SMTP id w4so10560368plz.1 for ; Mon, 21 Jan 2019 16:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=wMfLPHf5oXERuMFpLva5UotBcHDm/Y8t8Lq62CLGN40=; b=RlkTAoWXsInmKsPSu3njn1g9VlWNPIe28yhLY7I0jlXh99cuBP8kJpv9bNMygJFSdY T3BWBvAD8h9+aJefTsbAQQp354hRCQG/nggffif4L/Lm8ZozjaPcADKojlh/JmmI9gw5 K6SIqruo066eQTLB06m/jAim83v0qzNfT64HP//IGARQSqEyGKdJKIzEhmeXL4xrDPA2 d4QeRkNgRpDtVbLsWzpXcn3Npg8DTyXcoJ2IuQMphSY44Sb6MhjEmAR8bwFTDa9zxeIO kz+dubzTIwl46WkQ/p3tTuu1U28HKn3c+VfMsf/+X6gMMukAiuByKgJI2QLjqhA+shPl 2+Jg== Return-Path: Received: from bubble.grove.modra.org ([58.175.241.133]) by smtp.gmail.com with ESMTPSA id o66sm26731687pgo.75.2019.01.21.16.30.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 21 Jan 2019 16:30:01 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 91F7980652; Tue, 22 Jan 2019 10:59:57 +1030 (ACDT) Date: Tue, 22 Jan 2019 00:30:00 -0000 From: Alan Modra To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org Subject: Re: [RS6000] PR88614, output_operand: invalid %z value Message-ID: <20190122002957.GH29797@bubble.grove.modra.org> References: <20190106225918.GG3170@bubble.grove.modra.org> <20190118220213.GT14180@gate.crashing.org> <20190120133833.GF29797@bubble.grove.modra.org> <20190121121857.GG29797@bubble.grove.modra.org> <20190121142257.GC14180@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190121142257.GC14180@gate.crashing.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg01253.txt.bz2 On Mon, Jan 21, 2019 at 08:22:58AM -0600, Segher Boessenkool wrote: > On Mon, Jan 21, 2019 at 10:48:57PM +1030, Alan Modra wrote: > > Here's what the revised approach looks like, but without using new > > unspecs. Bootstrap and regression test on powerpc64le-linux and > > powerpc64-linux biarch completed, and testing on powerpc64le-linux > > with -mno-tls-markers. powerpc64-linux -mno-tls-markers testing still > > in progress. OK? > > This is easier to grok, thanks. Yes, and not having to edit __tls_get_addr call patterns is good too. > I think this would be nicer if you still used insn alternatives here. > What is needed for that? A new symbol constraint especially for __tls_get_addr? Actually two new constraints for ppc64, one for small model, the other for medium/large! No way. > The patch is okay for trunk (if it survives on at least all three linux > targets). Thanks! Happily it did, even with -mno-tls-markers. -- Alan Modra Australia Development Lab, IBM