From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113791 invoked by alias); 12 Dec 2018 16:26:23 -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 113775 invoked by uid 89); 12 Dec 2018 16:26: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=UD:eu, disclosure, HX-Get-Message-Sender-Via:sk:authent X-HELO: server28.superhosting.bg Received: from server28.superhosting.bg (HELO server28.superhosting.bg) (217.174.156.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Dec 2018 16:26:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dinux.eu; s=default; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References: In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=MVUVS40SOhvFltXl38/HdH/3d4vuxgiJ53wy1/ovuDI=; b=OrNwd9VXZCgRTnp9H7zQugvdCZ ff9TInPSzMcq58BqRWW/5XcLLTRsOlKPFluNeqIapQ+PZa4FFigUOKQsvJkeeSHQlE0DMDrDYMUG6 WSpRo/cVNTFwnYoNHBmtikVyOinxrx3qls9N9qSMTkj7c9ZsuK6sm/ZEsMqjwjd4J8HyK3MktUuHE AdQ04Dh4jx/SbKm6cRV7Job8a83rhSS0GPyhkaNUJFMTgydPRRq3B14QrWIsx+TKC9h6YXEsQ/th3 yrTVpZ4JUlj7YRjsqVKiNDTiz4SsCAQSo6JiCSax3srTJrmi858PZEXfM0GiCnU2n202WTZgt6o0/ cmLsx+vA==; Received: from [95.87.234.74] (port=49464 helo=tpdeb.localnet) by server28.superhosting.bg with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gX7Kt-0000DW-07; Wed, 12 Dec 2018 18:26:16 +0200 From: Dimitar Dimitrov To: Christophe Lyon Cc: Thomas Preudhomme , gcc Patches , Richard Sandiford , Thomas Preud'homme Subject: Re: [PATCH] [RFC] PR target/52813 and target/11807 Date: Wed, 12 Dec 2018 16:26:00 -0000 Message-ID: <4591520.WeSID5Fo3g@tpdeb> User-Agent: KMail/5.2.3 (Linux/4.9.0-8-amd64; KDE/5.28.0; x86_64; ; ) In-Reply-To: References: <20181209100856.14051-1-dimitar@dinux.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-OutGoing-Spam-Status: No, score=-0.5 X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00838.txt.bz2 On Wed, 12 Dec 2018 at 14:19:27 EET Christophe Lyon wrote: > 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"? Disclosure: I'm a GCC newbie. I expect that if I mark a HW register as "clobber", compiler would save its contents before executing the asm statement, and after that it would restore its contents. This is the GCC behaviour for all but the SP and PIC registers. That is why I believe that PR52813 is a valid bug. I'm not sure how GCC could recover if SP is clobbered. If SP is clobbered in such a way that GCC will not notice (e.g. thread switching), then why should GCC know about it in the first place? Regards, Dimitar