This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] [RFC] PR target/52813 and target/11807
- From: Christophe Lyon <christophe dot lyon at linaro dot org>
- To: Dimitar Dimitrov <dimitar at dinux dot eu>, Bernd Edlinger <bernd dot edlinger at hotmail dot de>, Segher Boessenkool <segher at kernel dot crashing dot org>, Christophe Lyon <christophe dot lyon at linaro dot org>, Thomas Preudhomme <thomas dot preudhomme at linaro dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Sandiford <richard dot sandiford at arm dot com>
- Date: Mon, 17 Dec 2018 13:53:51 +0100
- Subject: Re: [PATCH] [RFC] PR target/52813 and target/11807
- References: <DB7PR07MB53537B024F807B2F383C87B0E4A30@DB7PR07MB5353.eurprd07.prod.outlook.com> <85840089.MtehzfUrTt@tpdeb> <email@example.com>
On Mon, 17 Dec 2018 at 12:47, Richard Sandiford
> Dimitar Dimitrov <firstname.lastname@example.org> 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.
If we leave the error, maybe a more explanatory message would be helpful?
(along the lines of what I posted earlier in this thread, which may be