From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2548 invoked by alias); 22 Sep 2011 08:53:03 -0000 Received: (qmail 2538 invoked by uid 22791); 22 Sep 2011 08:53:02 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Sep 2011 08:52:47 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R6f1R-0000N1-04 for gcc@gcc.gnu.org; Thu, 22 Sep 2011 10:52:45 +0200 Received: from 79.161.10.130 ([79.161.10.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Sep 2011 10:52:44 +0200 Received: from david by 79.161.10.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Sep 2011 10:52:44 +0200 To: gcc@gcc.gnu.org From: David Brown Subject: Re: Volatile qualification on pointer and data Date: Thu, 22 Sep 2011 08:53:00 -0000 Message-ID: References: <4E7A3209.10508@gjlay.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 In-Reply-To: <4E7A3209.10508@gjlay.de> 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/msg00223.txt.bz2 On 21/09/2011 20:50, Georg-Johann Lay wrote: > 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. > That is /very/ different - you are talking about an "extern volatile const uint8_t readOnlySFR" declaration, or something effectively like: #define readOnlySFR (*(volatile const uint8_t *) 0x1234) Either way, what you are telling the compiler is that this item is "volatile", and may change it's value unbeknownst to the compiler, and that is "const", meaning that /your/ code may not change its value. That's fine, and consistent. It might sound strange at first - many people think "const" means the data is constant and cannot change, when in fact C has its one peculiar meaning for "const". What can't make sense is a /static/ "volatile const" which is /defined/ locally, rather than just declared. > 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. > Again, you are talking about a "volatile const" declaration of data that is defined externally, and that's okay. Also note that in this case the local static const data is not volatile - it is only accessed as a volatile through a pointer cast.