linux-mips-fnet
[Top] [All Lists]

Re: [patch] linux 2.4.9: Bad code in xchg_u32()

To: Jun Sun <jsun@mvista.com>
Subject: Re: [patch] linux 2.4.9: Bad code in xchg_u32()
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Wed, 17 Oct 2001 02:57:21 +0200
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <3BCCB979.FFBFE85B@mvista.com>; from jsun@mvista.com on Tue, Oct 16, 2001 at 03:49:29PM -0700
References: <Pine.GSO.3.96.1011016161735.19676E-100000@delta.ds2.pg.gda.pl> <20011017002947.A19789@dea.linux-mips.net> <3BCCB979.FFBFE85B@mvista.com>
User-agent: Mutt/1.2.5i
On Tue, Oct 16, 2001 at 03:49:29PM -0700, Jun Sun wrote:

> > >  Unfortunately, gcc 2.95.3 doesn't want to accept a "=R" output constraint
> > > here so I had to use "=m".  It looks like a bug in gcc.  Until it is fixed
> > > the "R" input constraint here is sufficient for gcc to know it has m
> > > already available in one of registers.  I added ".set nomacro" to make
> > > sure the second ll fits in the BDS as well.
> > 
> > I've added the "memory" clobber back; xchg() is expected to imply a memory
> > barrier.
> > 
> > "R" indeed seems to be fishy; I can't compile the kernel if I remove
> > the volatile from the first argument of xchg_u32().  I'd feel safer if
> > we could use "m" until we can be sure "R" works fine.
> 
> Is there any reason to think "R" *should* be better than "m"?

Single instruction loads that is no macros.

  Ralf

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