From: "David Schwartz" <davids@webmaster.com>
To: <mrmacman_g4@mac.com>
Cc: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
       <schwab@suse.de>
Subject: RE: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away
Date: Thu, 7 Dec 2006 20:22:17 -0800
Message-ID: <MDEHLPKNGKAHNMBLJOLKCEINADAC.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <A1480C13-162B-4593-A378-05FE43D1D0D2@mac.com>
Reply-To: davids@webmaster.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1122
Lines: 24


> In that case it specifies that any evaluation of "*foo" in an rvalue
> context specifies a read (with a few exceptions for G++ where the C++
> language generally confuses things).  Specifically it mentions the
> statement "*src;" and discusses the statement as providing "a void
> context".  In other words, a statement such as "(void)(expr);" is
> redundant because the statement already implies void context and the
> extra cast-to-void is just extra text.  As such "(void)(*src);" on a
> "volatile int *src;" is documented to force a read of "*src".  Now,
> if you actually _use_ the result over just casting it to void and
> discarding it, then GCC can provide no _less_ guarantee with regards
> to the read-and-store than it provides to the read-and-discard.

I read over this section and didn't realize the implications of the void
context. I now agree with you.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/