From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2387 invoked by alias); 21 Sep 2011 18:51:37 -0000 Received: (qmail 2378 invoked by uid 22791); 21 Sep 2011 18:51:36 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Sep 2011 18:51:21 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT2k715jHQaJercGOZE+TiTS5oyq0h49O9Ps= X-RZG-CLASS-ID: mo00 Received: from [192.168.2.100] (dslb-084-058-199-117.pools.arcor-ip.net [84.58.199.117]) by smtp.strato.de (fruni mo13) (RZmta 26.7) with ESMTPA id y0585dn8LIbxtE ; Wed, 21 Sep 2011 20:51:16 +0200 (MEST) Message-ID: <4E7A3209.10508@gjlay.de> Date: Wed, 21 Sep 2011 18:51:00 -0000 From: Georg-Johann Lay User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: David Brown CC: gcc@gcc.gnu.org Subject: Re: Volatile qualification on pointer and data References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg00218.txt.bz2 David Brown schrieb: > On 21/09/2011 15:57, Ian Lance Taylor wrote: > >> David Brown writes: >> >>> On 21/09/2011 10:21, Paulo J. Matos wrote: >>> >>>> On 21/09/11 08:03, David Brown wrote: >>>> >>>>> Asking to read it by a volatile read does not >>>>> change the nature of "foo" - the compiler can still implement it as a >>>>> compile-time constant. >>>> >>>> But since I am accessing the data through the pointer and the pointer >>>> qualifies the data as volatile, shouldn't the compiler avoid this kind >>>> of optimization for reads through the pointer? >>> >>> My thought is that the nature of "foo" is independent of how it is >>> accessed. On the other hand, some uses of a variable will affect its >>> implementation - if you take the address of "foo" and pass that on to >>> an external function or data, then the compiler would have to generate >>> "foo" in memory (but in read-only memory, and it can still assume its >>> value does not change). So I am not sure what the "correct" behaviour >>> is here - I merely ask the question. >>> >>> Fortunately, this situation is not going to occur in real code. >> >> I think your description is supported by the standard. However, I also >> think that gcc should endeavor to fully honor the volatile qualifier in >> all cases, because that is least surprising to the programmer. This is >> not a case where we should let optimization override the programmer's >> desire; by using volatile, the programmer has explicitly told us that >> they do not want any optimization to occur. ACK. > That makes sense - the principle of least surprise. And since this > situation would not occur in real code (at least, not code that is > expected to do something useful other than test the compiler's code > generation), there is no harm in making sub-optimal object code. > > Are there any warning flags for "programmer doing something technically > legal but logically daft", that could be triggered by such cases? :-) The combination of const and volatile can be reasonable in real world code. One example is a special function register (SFR) that is read-only but can be altered by hardware. Second example is a lookup table that can be changed after building the software, e.g. you have some calibration data that has to be drawn from the environment (drift of sensors, inductivity of motor windings, offset of actors, etc). In such a case you want to read the data from the lookup table in, say, .rodata. By no means you want the compiler to insert/propagate known values from the lookup table to immediate operands in instructions. That's exacly what "const volatile" does. Johann