From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757468Ab0GNTCH (ORCPT ); Wed, 14 Jul 2010 15:02:07 -0400 Received: from terminus.zytor.com ([198.137.202.10]:53732 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754264Ab0GNTCE (ORCPT ); Wed, 14 Jul 2010 15:02:04 -0400 Message-ID: <4C3E096B.8050505@zytor.com> Date: Wed, 14 Jul 2010 12:00:59 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: "H.J. Lu" CC: Jeremy Fitzhardinge , Linus Torvalds , Peter Palfrader , Avi Kivity , Greg KH , linux-kernel@vger.kernel.org, stable@kernel.org, stable-review@kernel.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, Glauber Costa , Zachary Amsden , Marcelo Tosatti Subject: Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock References: <20100707124731.GJ15122@anguilla.noreply.org> <4C359D5A.1050906@redhat.com> <20100713102350.GW15122@anguilla.noreply.org> <4C3C68C8.4060409@redhat.com> <20100713141902.GB15122@anguilla.noreply.org> <4C3C8CE5.1080705@redhat.com> <20100713162207.GC15122@anguilla.noreply.org> <4C3C9589.4090602@redhat.com> <4C3C96EC.8060901@redhat.com> <4C3C9839.4090404@redhat.com> <20100713172526.GE15122@anguilla.noreply.org> <4C3CAE8F.10900@goop.org> <4C3CE560.5050701@zytor.com> <4C3CFB8B.1090804@goop.org> <4C3DF1BE.2070404@goop.org> <4C3DF447.1000801@zytor.com> <4C3DF519.6030406@goop.org> <4C3DF7AF.7010402@zytor.com> <4C3DFA88.5020007@goop.org> <4C3DFD12.3050700@zytor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/14/2010 11:18 AM, H.J. Lu wrote: > > There are some discussions on: > > http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html > http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00001.html > > Are they related? > Not directly as far as I can tell. The issue is if gcc can ever reorder, duplicate or elide a volatile operation (either asm volatile or a volatile-annotated memory reference.) In my (and Linus') opinion, this would be an incredibly serious bug. The gcc 4.4 issue, which is separate from the definition issue, is that it seems to assume that it can elide references to "const volatile" objects. "const volatile" should mean a value that could change at any time but which is a bug to write to -- for example a readonly hardware register. -hpa