From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21109 invoked by alias); 10 Jan 2019 21:56: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 21099 invoked by uid 89); 10 Jan 2019 21:56: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=52813, H*f:sk:DB7PR07, H*f:sk:AM6PR07, H*f:sk:87lg3vi 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; Thu, 10 Jan 2019 21:56:33 +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 6CF83A78; Thu, 10 Jan 2019 13:56:31 -0800 (PST) Received: from localhost (unknown [10.32.98.35]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0BF973F6CF; Thu, 10 Jan 2019 13:56:29 -0800 (PST) From: Richard Sandiford To: Jakub Jelinek Mail-Followup-To: Jakub Jelinek ,Segher Boessenkool , Bernd Edlinger , Dimitar Dimitrov , Christophe Lyon , Thomas Preudhomme , "gcc-patches\@gcc.gnu.org" , richard.sandiford@arm.com Cc: Segher Boessenkool , Bernd Edlinger , 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> <87zhs84374.fsf@arm.com> <20190110212629.GZ30353@tucnak> Date: Thu, 10 Jan 2019 21:56:00 -0000 In-Reply-To: <20190110212629.GZ30353@tucnak> (Jakub Jelinek's message of "Thu, 10 Jan 2019 22:26:29 +0100") Message-ID: <8736q041o3.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/msg00579.txt.bz2 Jakub Jelinek writes: > On Thu, Jan 10, 2019 at 09:23:27PM +0000, Richard Sandiford wrote: >> > "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. > > "noreturn" asm can be done already now, just use > asm volatile ("..." ...); > __builtin_unreachable (); > > I think there is no need to add a new syntax for that. ISTR the point was that the PowerPC ABI places requirements on functions with noreturn calls and the attribute would help GCC do the right thing in those circumstances. So "noreturn" would imply a call that doesn't return, rather than just an infinite loop. Richard