public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Dimitar Dimitrov <dimitar@dinux.eu>
Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,
	 Segher Boessenkool <segher@kernel.crashing.org>,
	 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: Mon, 17 Dec 2018 11:47:00 -0000	[thread overview]
Message-ID: <87woo84boh.fsf@arm.com> (raw)
In-Reply-To: <85840089.MtehzfUrTt@tpdeb> (Dimitar Dimitrov's message of "Sun,	16 Dec 2018 18:13:57 +0200")

Dimitar Dimitrov <dimitar@dinux.eu> writes:
> On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
>> Hi,
>> 
>> if I understood that right, then clobbering sp is and has always been
>> ignored.

PR77904 was about the clobber not being ignored, so the behaviour
hasn't been consistent.

I'm also not sure it was always ignored in recent sources.  The clobber
does get added to the associated rtl insn, and it'd be surprising if
that never had an effect.

>> If that is right, then I would much prefer a warning, that says exactly
>> that, because that would also help to understand why removing that clobber
>> statement is safe even for old gcc versions.

If the asm does leave sp with a different value, then it's never been safe,
regardless of the gcc version.  That's why an error seems more appropriate.

> Thank you. Looks like general consensus is to have a warning. See attached 
> patch that switches the error to a warning.

I don't think there's a good reason to treat this differently from the
preexisting PIC register error.  If the argument for making it a warning
rather than an error is that the asm might happen to work by accident,
then the same is true for the PIC register.

Thanks,
Richard

  reply	other threads:[~2018-12-17 11:47 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 [this message]
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
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=87woo84boh.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=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).