From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58658 invoked by alias); 10 Jan 2019 21:23:34 -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 58648 invoked by uid 89); 10 Jan 2019 21:23:34 -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=controversial, 52813, Bernd, Meanwhile 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; Thu, 10 Jan 2019 21:23:32 +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 C1CCFA78; Thu, 10 Jan 2019 13:23:30 -0800 (PST) Received: from localhost (unknown [10.32.98.35]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 603C23F6CF; Thu, 10 Jan 2019 13:23:29 -0800 (PST) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool ,Bernd Edlinger , Jakub Jelinek , Dimitar Dimitrov , Christophe Lyon , Thomas Preudhomme , "gcc-patches\@gcc.gnu.org" , richard.sandiford@arm.com Cc: Bernd Edlinger , Jakub Jelinek , Dimitar Dimitrov , Christophe Lyon , Thomas Preudhomme , "gcc-patches\@gcc.gnu.org" Subject: Re: [PATCH] [RFC] PR target/52813 and target/11807 References: <85840089.MtehzfUrTt@tpdeb> <20190107092337.GM30353@tucnak> <87lg3vicg5.fsf@arm.com> <20190110132111.GZ14180@gate.crashing.org> Date: Thu, 10 Jan 2019 21:23:00 -0000 In-Reply-To: <20190110132111.GZ14180@gate.crashing.org> (Segher Boessenkool's message of "Thu, 10 Jan 2019 07:21:12 -0600") Message-ID: <87zhs84374.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: 2019-01/txt/msg00575.txt.bz2 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 regression 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_needed. > Whatever happens from that is the target's business. Do you mean the asm clobber or -fno-omit-frame-pointer? If the option, then yeah, and that was exactly what was controversial :-) >> The effect on the redzone seems like something that should be specified >> explicitly rather than as an (accidental?) side effect of listing the >> sp in the clobber list. Maybe this would be another use for the "asm >> attributes" proposal. "noreturn" was another attribute suggested on >> IRC yesterday. > > Redzone is target-dependent. Right. Target-dependent asm attributes wouldn't be a problem though. Most other things about an asm are target-dependent anyway. > "noreturn"... What would that mean, *exactly*? It cannot execute any > code the compiler can see, so such asm is better off as real asm anyway > (not inline asm). "Exactly" is a strong word, and this wasn't my proposal, but... I think it would act like a noreturn call to an unknown function. Output operands wouldn't make sense, and arguably clobbers wouldn't either. Thanks, Richard >> But either way, the general feeling seems to be that going straight to a >> hard error is too harsh, since there's quite a bit of existing code that >> has the clobber. This patch implements the compromise discussed on IRC >> yesterday of making it a -Wdeprecated warning instead. > > The patch looks fine to me. Thanks! > > > Segher