From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] x86: fix wait code asm() constraints Date: Fri, 03 Aug 2012 13:08:43 +0100 Message-ID: References: <501BD3ED02000078000927F6@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <501BD3ED02000078000927F6@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 03/08/2012 12:36, "Jan Beulich" wrote: >> I'm confused. The registers have the same values at the start and the en= d of >> the asm statement. How can it possibly matter, even in theory, whether t= hey >> temporarily change in the middle? Is this fairly strong assumption writt= en >> down in the gcc documentation anywhere? > = > It's in the specification of the & modifier: > = > "=8C&=B9 Means (in a particular alternative) that this operand is an > earlyclobber operand, which is modified before the instruction > is finished using the input operands. Therefore, this operand > may not lie in a register that is used as an input operand or as > part of any memory address." > = > Of course, here we're not having any other operands, which > is why at least at present getting this wrong does no harm. Yep, okay, that makes sense. Especially the use of an input operand to form a memory address, although of course that cannot happen in our specific case here. I have acked your patch, although I'd like an update to the patch comment. Thanks, -- Keir