All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@avtrex.com>
To: Ralf Baechle <ralf@linux-mips.org>, GCC Mailing List <gcc@gcc.gnu.org>
Cc: MIPS Linux List <linux-mips@linux-mips.org>,
	Richard Sandiford <rdsandiford@googlemail.com>
Subject: Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins'	instructions.
Date: Wed, 11 Jun 2008 10:43:57 -0700	[thread overview]
Message-ID: <48500EDD.404@avtrex.com> (raw)
In-Reply-To: <20080611172950.GA16600@linux-mips.org>

Ralf Baechle wrote:
> On Wed, Jun 11, 2008 at 10:04:25AM -0700, David Daney wrote:
> 
>> The third operand to 'ins' must be a constant int, not a register.
>>
>> Signed-off-by: David Daney <ddaney@avtrex.com>
>> ---
>> include/asm-mips/bitops.h |    6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
>> index 6427247..9a7274b 100644
>> --- a/include/asm-mips/bitops.h
>> +++ b/include/asm-mips/bitops.h
>> @@ -82,7 +82,7 @@ static inline void set_bit(unsigned long nr, volatile unsigned long *addr)
>> 		"2:	b	1b					\n"
>> 		"	.previous					\n"
>> 		: "=&r" (temp), "=m" (*m)
>> -		: "ir" (bit), "m" (*m), "r" (~0));
>> +		: "i" (bit), "m" (*m), "r" (~0));
>> #endif /* CONFIG_CPU_MIPSR2 */
>> 	} else if (cpu_has_llsc) {
>> 		__asm__ __volatile__(
> 
> An old trick to get gcc to do the right thing.  Basically at the stage when
> gcc is verifying the constraints it may not yet know that it can optimize
> things into an "i" argument, so compilation may fail if "r" isn't in the
> constraints.  However we happen to know that due to the way the code is
> written gcc will always be able to make use of the "i" constraint so no
> code using "r" should ever be created.
> 
> The trick is a bit ugly; I think it was used first in asm-i386/io.h ages ago
> and I would be happy if we could get rid of it without creating new problems.
> Maybe a gcc hacker here can tell more?

It is not nice to lie to GCC.

CCing GCC and Richard in hopes that a wider audience may shed some light on the issue.

David Daney

  reply	other threads:[~2008-06-11 17:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-11 17:04 Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions David Daney
2008-06-11 17:12 ` Ralf Baechle
2008-06-11 17:29 ` Ralf Baechle
2008-06-11 17:43   ` David Daney [this message]
2008-06-12  8:27     ` Richard Sandiford
2008-06-12 16:30       ` David Daney
2008-06-12 18:21         ` Richard Sandiford
2008-06-12 20:10           ` David Daney
2008-06-13 14:28             ` Ralf Baechle

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=48500EDD.404@avtrex.com \
    --to=ddaney@avtrex.com \
    --cc=gcc@gcc.gnu.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rdsandiford@googlemail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.