From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28619 invoked by alias); 24 Jan 2007 23:57:51 -0000 Received: (qmail 28608 invoked by uid 22791); 24 Jan 2007 23:57:51 -0000 X-Spam-Check-By: sourceware.org Received: from VLSI1.ULTRA.NYU.EDU (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org (qpsmtpd/0.31) with SMTP; Wed, 24 Jan 2007 23:57:46 +0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA15877; Wed, 24 Jan 07 19:03:25 EST From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10701250003.AA15877@vlsi1.ultra.nyu.edu> Date: Wed, 24 Jan 2007 23:57:00 -0000 To: mark@codesourcery.com Subject: Re: [PATCH] Tree SRA and atomicity/volatility Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, richard.guenther@gmail.com In-Reply-To: <45B7A5E8.3080102@codesourcery.com> References: <200701061422.39157.ebotcazou@adacore.com> <45B63E9B.9090909@codesourcery.com> <84fc9c000701230924g37ed4f42vca8d7ae0c1ef6e52@mail.gmail.com> <45B6643C.6000800@codesourcery.com> <84fc9c000701231257u7fb1f10rdd3255be8aa69686@mail.gmail.com> <10701240137.AA23316@vlsi1.ultra.nyu.edu> <84fc9c000701240127x2fe9492bq355cd35260e7b55e@mail.gmail.com> <10701241307.AA01425@vlsi1.ultra.nyu.edu> <84fc9c000701240533p217a2735i8e42634e07029df7@mail.gmail.com> <45B7A5E8.3080102@codesourcery.com> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-01/txt/msg02050.txt.bz2 > As a programmer, I would try hard to minimize my reliance on volatile > for exactly this reason. On a 32-bit machine, I'd expect the compiler > to handle "volatile int" by using 32-bit word-aligned loads/stores. > But, I would try to avoid "struct S { volatile char a; volatile char b; > }", if reading/writing "a" and "b" had side-effects, because I wouldn't > know exactly what that might do. I'd use inline assembly if I needed > that fine level of control. I know you and most people contributing to this thread know this, but just for others who might not be thinking about it, there's *another* purpose of volatile that all of us agree on. If there's an object X of struct S and you have X.a = 5; if (X.a == 5) ... That second comparison must *not* be optimized away. That's the core of the meaning of volatile: that two separate reads must always be done separately. We can argue about what it means in a *single* read, but it always means *something* to declare anything volatile, so we can never make it invalid.