From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119425 invoked by alias); 10 Jan 2019 22:32:10 -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 119402 invoked by uid 89); 10 Jan 2019 22:32:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=BAYES_50,FREEMAIL_FROM,KAM_MANYTO,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=controversial, 52813, H*RU:sk:EUR02-H, Hx-spam-relays-external:sk:HE1EUR0 X-HELO: EUR02-HE1-obe.outbound.protection.outlook.com Received: from mail-oln040092068044.outbound.protection.outlook.com (HELO EUR02-HE1-obe.outbound.protection.outlook.com) (40.92.68.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Jan 2019 22:32:06 +0000 Received: from HE1EUR02FT039.eop-EUR02.prod.protection.outlook.com (10.152.10.53) by HE1EUR02HT198.eop-EUR02.prod.protection.outlook.com (10.152.11.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13; Thu, 10 Jan 2019 22:32:03 +0000 Received: from AM6PR07MB5608.eurprd07.prod.outlook.com (10.152.10.59) by HE1EUR02FT039.mail.protection.outlook.com (10.152.11.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Thu, 10 Jan 2019 22:32:03 +0000 Received: from AM6PR07MB5608.eurprd07.prod.outlook.com ([fe80::68b1:73c3:455d:de2a]) by AM6PR07MB5608.eurprd07.prod.outlook.com ([fe80::68b1:73c3:455d:de2a%2]) with mapi id 15.20.1516.016; Thu, 10 Jan 2019 22:32:03 +0000 From: Bernd Edlinger To: Segher Boessenkool , Jakub Jelinek , Dimitar Dimitrov , Christophe Lyon , Thomas Preudhomme , "gcc-patches@gcc.gnu.org" , "richard.sandiford@arm.com" Subject: Re: [PATCH] [RFC] PR target/52813 and target/11807 Date: Thu, 10 Jan 2019 22:32:00 -0000 Message-ID: References: <85840089.MtehzfUrTt@tpdeb> <20190107092337.GM30353@tucnak> <87lg3vicg5.fsf@arm.com> <20190110132111.GZ14180@gate.crashing.org> <87zhs84374.fsf@arm.com> In-Reply-To: <87zhs84374.fsf@arm.com> x-microsoft-original-message-id: Content-Type: text/plain; charset="Windows-1252" Content-ID: <4F0B177164240046A2793D115835D2F5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2019-01/txt/msg00583.txt.bz2 On 1/10/19 10:23 PM, Richard Sandiford wrote: > Segher Boessenkool writes: >> On Tue, Jan 08, 2019 at 12:03:06PM +0000, Richard Sandiford wrote: >>> Bernd Edlinger writes: >>>> Meanwhile I found out, that the stack clobber has only been ignored up= to >>>> gcc-5 (at least with lra targets, not really sure about reload targets= ). >>>> From gcc-6 on, with the exception of PR arm/77904 which was a regressi= on due >>>> to the underlying lra change, but fixed later, and back-ported to gcc-= 6.3.0, >>>> this works for all targets I tried so far. >>>> >>>> To me, it starts to look like a rather unique and useful feature, that= I would >>>> like to keep working. >>> >>> Not sure what you mean by "unique". But forcing a frame is a bit of >>> a slippery concept. Force it where? For the asm only, or the whole >>> function? This depends on optimisation and hasn't been consistent >>> across GCC versions, since it depends on the shrink-wrapping >>> optimisation. (There was a similar controversy a while ago about >>> to what extent -fno-omit-frame-pointer should "force a frame".) >> >> It's not forcing a frame currently: it's just setting frame_pointer_need= ed. >> Whatever happens from that is the target's business. >=20 > Do you mean the asm clobber or -fno-omit-frame-pointer? If the option, > then yeah, and that was exactly what was controversial :-) >=20 Yes, what I meant is the asm clobber sets frame_pointer_needed, on the function where this asm is used, that sounded to me like it would have an impact on the frame pointer. What I also expected, is that if an asm is accessing a local via "m" then the a SP+x reference will be elimitated to a FP+x, reference, which would allow the asm to push something on the stack, and the memory references would remain valid, as long as the stack is _restored_, again in the same asm. I mean in case of register shortage. I was not thinking about noreturn at all. But if -fno-omit-frame-pointer does the same, and that is not sufficient to for forcing a frame pointer, because it is a target dependent, then I wonder how ASAN is supposed to work on such a target. But anyway I guess, your patch is fine. Thanks Bernd.=20