| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [patch] linux 2.4.9: Bad code in xchg_u32(), Jun Sun |
|---|---|
| Next by Date: | Worm bombardment., Ralf Baechle |
| Previous by Thread: | Re: [patch] linux 2.4.9: Bad code in xchg_u32(), Jun Sun |
| Next by Thread: | Re: [patch] linux 2.4.9: Bad code in xchg_u32(), Maciej W. Rozycki |
| Indexes: | [Date] [Thread] [Top] [All Lists] |