linux-mips
[Top] [All Lists]

Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions.

To: Ralf Baechle <ralf@linux-mips.org>, GCC Mailing List <gcc@gcc.gnu.org>
Subject: Re: Resend: [PATCH] [MIPS] Fix asm constraints for 'ins' instructions.
From: David Daney <ddaney@avtrex.com>
Date: Wed, 11 Jun 2008 10:43:57 -0700
Cc: MIPS Linux List <linux-mips@linux-mips.org>, Richard Sandiford <rdsandiford@googlemail.com>
In-reply-to: <20080611172950.GA16600@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <48500599.9080807@avtrex.com> <20080611172950.GA16600@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.14 (X11/20080501)
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

<Prev in Thread] Current Thread [Next in Thread>