From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39793 invoked by alias); 17 Dec 2018 18:46:24 -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 39755 invoked by uid 89); 17 Dec 2018 18:46:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,SPF_PASS autolearn=no version=3.3.2 spammy=H*Ad:D*eu, accident, pr77904, PR77904 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Dec 2018 18:46:20 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 08096EBD; Mon, 17 Dec 2018 10:46:19 -0800 (PST) Received: from localhost (unknown [10.32.99.101]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BD2033F675; Mon, 17 Dec 2018 10:46:17 -0800 (PST) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool ,Dimitar Dimitrov , Bernd Edlinger , Christophe Lyon , Thomas Preudhomme , "gcc-patches\@gcc.gnu.org" , richard.sandiford@arm.com Cc: Dimitar Dimitrov , Bernd Edlinger , Christophe Lyon , Thomas Preudhomme , "gcc-patches\@gcc.gnu.org" Subject: Re: [PATCH] [RFC] PR target/52813 and target/11807 References: <85840089.MtehzfUrTt@tpdeb> <87woo84boh.fsf@arm.com> <20181217155425.GW3803@gate.crashing.org> Date: Mon, 17 Dec 2018 18:46:00 -0000 In-Reply-To: <20181217155425.GW3803@gate.crashing.org> (Segher Boessenkool's message of "Mon, 17 Dec 2018 09:54:26 -0600") Message-ID: <871s6g0z5z.fsf@arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-12/txt/msg01245.txt.bz2 Segher Boessenkool writes: > On Mon, Dec 17, 2018 at 11:47:42AM +0000, Richard Sandiford wrote: >> Dimitar Dimitrov writes: >> > On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote: >> >> Hi, >> >> >> >> if I understood that right, then clobbering sp is and has always been >> >> ignored. >> >> PR77904 was about the clobber not being ignored, so the behaviour >> hasn't been consistent. >> >> I'm also not sure it was always ignored in recent sources. The clobber >> does get added to the associated rtl insn, and it'd be surprising if >> that never had an effect. > > Yes, you will usually get a frame pointer. My point was that the epilogue > will restore your stack pointer both with and without the asm clobber. I'm not confident that's the only effect though. Also, we didn't use a frame in PR77904, and using a frame would have been the wrong thing to do. >> I don't think there's a good reason to treat this differently from the >> preexisting PIC register error. If the argument for making it a warning >> rather than an error is that the asm might happen to work by accident, >> then the same is true for the PIC register. > > Yes. As well as quite a few more registers, many of those specific to > the target. And there are many more things you can do terribly wrong in > inline assembler, of course, most of which we can never detect. Right. And I don't think anyone's suggesting GCC can detect everything. It can only police the things it knows about, which include the input, output and clobber clauses. What makes the PIC register and sp worth special attention is that changing their values would in general invalidate other code that GCC generates itself. It's not just about whether the asm has the effect the author wanted (whatever that was). FWIW, I don't think we should go on a proactive hunt for other registers to complain about. Thanks, Richard