This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Volatile qualification on pointer and data


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.


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? :-)




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]