On Wed, 17 Oct 2001, Ralf Baechle wrote: > I've added the "memory" clobber back; xchg() is expected to imply a memory > barrier. I'm not sure what you mean. The "memory" clobber only means random memory can get modified so gcc must dispose of all variables cached in registers and reload them from memory. Is xchg() meant to do so? What for? > "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. Sure we can, at the expense of obfuscating the code and wasting a register -- we may use la explicitly. But I hate workarounds -- they tend to live forever and keep the real bug unfixed. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
