From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85840 invoked by alias); 14 Dec 2018 13:49:46 -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 85829 invoked by uid 89); 14 Dec 2018 13:49:46 -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=survive, H*f:sk:87woohs, U*christophe.lyon, christophelyonlinaroorg X-HELO: foss.arm.com Received: from usa-sjc-mx-foss1.foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Dec 2018 13:49:44 +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 E9ED680D; Fri, 14 Dec 2018 05:49:42 -0800 (PST) Received: from localhost (unknown [10.32.99.101]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D1F783F575; Fri, 14 Dec 2018 05:49:41 -0800 (PST) From: Richard Sandiford To: Christophe Lyon Mail-Followup-To: Christophe Lyon ,Thomas Preudhomme , dimitar@dinux.eu, gcc Patches , "Thomas Preud'homme" , richard.sandiford@arm.com Cc: Thomas Preudhomme , dimitar@dinux.eu, gcc Patches , "Thomas Preud'homme" Subject: Re: [PATCH] [RFC] PR target/52813 and target/11807 References: <20181209100856.14051-1-dimitar@dinux.eu> <87woohsk32.fsf@arm.com> <2807771.CbC4dySGB1@tpdeb> <87woog9i32.fsf@arm.com> Date: Fri, 14 Dec 2018 13:49:00 -0000 In-Reply-To: (Christophe Lyon's message of "Wed, 12 Dec 2018 14:19:27 +0100") Message-ID: <87ftv0nrpn.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/msg01053.txt.bz2 (Maybe the discussion has moved on from this already -- sorry if so) Christophe Lyon writes: > On Wed, 12 Dec 2018 at 12:21, Thomas Preudhomme > wrote: >> >> So my understanding is that the original code (CMSIS library) used to >> clobber sp because the asm statement was actually changing the sp. >> That in turn led GCC to try to save and restore sp which is not what >> CMSIS was expecting to happen. Changing sp without clobber as done now >> is probably the right solution and r242693 can be reverted. That will >> remove the failing test. >> > > OK, I read PR52813 too, but I'm not sure to fully understand the new status. > My understanding is that since this patch was committed, if an asm statement > clobbers sp, it is now allowed to actually declare it as clobber (this patch > generates an error in such a case). > So the user is now expected to lie to the compiler when writing to > this kind of register (sp, pic register), by not declaring it as "clobber"? The user isn't expected to lie. The point is that GCC simply doesn't support asms that leave the stack pointer with a different value from before, and IMO never has. If that happened to work in some cases then it was purely an accident. The PRs also show disagreement about what GCC should do for an asm like that. The asm in PR52813 temporarily changed the stack pointer and the bug was that GCC didn't restore the original value afterwards. The asm in PR77904 was trying to set the stack pointer to an entirely new value and the bug was the GCC did restore the original value afterwards, defeating the point. This wouldn't be the first time that there's disagreement about what the behaviour should be. But IMO we can't support either reliably. Spilling sp is dangerous in general because we might need the stack for the reload, or we might accidentally try to reload something else before restoring the stack pointer. And continuing with a new sp provided by the asm could lead to all sorts of problems. (AIUI, the point of PR77904 was that it would also be wrong for GCC to set up a frame pointer and restore the sp from that frame pointer on function exit. The new sp value was supposed to survive. So the answer isn't simply "use a frame pointer".) Thanks, Richard