public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
	 Bernd Edlinger <bernd.edlinger@hotmail.de>,
	 Dimitar Dimitrov <dimitar@dinux.eu>,
	 Christophe Lyon <christophe.lyon@linaro.org>,
	 Thomas Preudhomme <thomas.preudhomme@linaro.org>,
	 "gcc-patches\@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] [RFC] PR target/52813 and target/11807
Date: Thu, 10 Jan 2019 21:56:00 -0000	[thread overview]
Message-ID: <8736q041o3.fsf@arm.com> (raw)
In-Reply-To: <20190110212629.GZ30353@tucnak> (Jakub Jelinek's message of "Thu,	10 Jan 2019 22:26:29 +0100")

Jakub Jelinek <jakub@redhat.com> 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

  reply	other threads:[~2019-01-10 21:56 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-16 14:36 Bernd Edlinger
2018-12-16 16:14 ` Dimitar Dimitrov
2018-12-17 11:47   ` Richard Sandiford
2018-12-17 12:54     ` Christophe Lyon
2018-12-17 13:35       ` Richard Sandiford
2018-12-17 13:42         ` Christophe Lyon
2018-12-17 14:05           ` Bernd Edlinger
2018-12-17 14:10         ` Bernd Edlinger
2018-12-17 15:55     ` Segher Boessenkool
2018-12-17 18:46       ` Richard Sandiford
2018-12-17 20:15         ` Bernd Edlinger
2018-12-19  6:40           ` Dimitar Dimitrov
2018-12-19  9:29             ` Segher Boessenkool
2018-12-18 14:16     ` Bernd Edlinger
2018-12-18 15:14       ` Bernd Edlinger
2019-01-07  9:23   ` Jakub Jelinek
2019-01-07 21:51     ` Bernd Edlinger
2019-01-08 12:03       ` Richard Sandiford
2019-01-10 13:21         ` Segher Boessenkool
2019-01-10 21:23           ` Richard Sandiford
2019-01-10 21:26             ` Jakub Jelinek
2019-01-10 21:56               ` Richard Sandiford [this message]
2019-01-11 12:26                 ` Segher Boessenkool
2019-01-10 22:32             ` Bernd Edlinger
2019-01-11 12:18             ` Segher Boessenkool
2019-01-11 12:23               ` Richard Sandiford
2019-01-11 22:59         ` Jeff Law
2019-01-17 14:27           ` Christophe Lyon
2019-01-18  9:49             ` Richard Sandiford
  -- strict thread matches above, loose matches on Subject: below --
2018-12-09 10:09 Dimitar Dimitrov
2018-12-10 11:21 ` Richard Sandiford
2018-12-10 19:36   ` Dimitar Dimitrov
2018-12-11 15:52     ` Richard Sandiford
2018-12-12  9:42       ` Christophe Lyon
2018-12-12 10:03         ` Christophe Lyon
2018-12-12 16:39           ` Dimitar Dimitrov
2018-12-12 10:30         ` Thomas Preudhomme
2018-12-12 11:21           ` Thomas Preudhomme
2018-12-12 13:19             ` Christophe Lyon
2018-12-12 15:13               ` Christophe Lyon
2018-12-12 15:35                 ` Thomas Preudhomme
2018-12-12 16:26               ` Dimitar Dimitrov
2018-12-13 14:49                 ` Segher Boessenkool
2018-12-13 22:21                   ` Dimitar Dimitrov
2018-12-14  8:52                     ` Segher Boessenkool
2018-12-16  8:43                       ` Dimitar Dimitrov
2018-12-17 15:23                         ` Segher Boessenkool
2018-12-14 13:49               ` Richard Sandiford
2018-12-15 15:38                 ` Segher Boessenkool
2018-12-12 11:24 ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8736q041o3.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --cc=bernd.edlinger@hotmail.de \
    --cc=christophe.lyon@linaro.org \
    --cc=dimitar@dinux.eu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=segher@kernel.crashing.org \
    --cc=thomas.preudhomme@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).