Re: Volatile qualification on pointer and data

[David Brown <david@westcontrol.com>]

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<david@westcontrol.com> 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.