This is the mail archive of the 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: Assignment to volatile objects

On Tue, 31 Jan 2012 00:38:15 +0100
Georg-Johann Lay <> wrote:

> A warning would be much of a help to write unambiguous, robust code.
> So the question is rather why user refuses to write robust code in the 
> first place once there is a warning.

The user (me, in this case) does not refuse writing robust code, because he
has no other choice, warning or not. The user is kindly asking to accomodate
his wish to write concise and more elegant code which is not five times
longer just to get around a language ambiguity (i.e. robust).

> IMHO it's about weigh cluttering up compiler souces with zillions of 
> command line options like
> - how to resolve a = b = c; if b is volatile.
> - how to resolve i = i++;
> - how to resolve f(i++, i++);
> - etc.
> against benefit for the user. I don't really see benefit.

I think there is a rather important difference between the volatile case 
and the others. Accessing a volatile is a side effect and so is the
postincrementing of the object. In the increment case you do know that the
side effects will happen before the next sequence point, you just do not know
exactly when within the two enclosing sequence points. With the a=b=0 case the
side effect of reading b may or may not happen at all. That, I think, is a
major difference.

In fact, I think there is an even bigger ambiguity with the volatile. Consider
the case of the single statement of a = 0; where a is volatile.

a=0; is an expression statement. Such a statement is evaluated as a void
expression for its side effects, as per A void expression is an
expression of which the value is discarded, as per Thus, the value of
a=0 should be calculated and then discarded. Since evaluating the value of
that expression when 'a' is volatile may or may not read 'a' back, as per, the compiler thus has every right to randomly generate or not a read
after writing the 0 to a. That is, a simple assignment has an unpredictable
side effect on volatile objects. Nothing in the standard says that you must
not actually calculate the value of an expression statement before
discarding it, actually it explicitely states in that you must not
omit parts of an expression evaluation which have side effects even if
the expression's value is not used. The read-back of a volatile lhs of an
expression is a side effect, which, according to the standard, the compiler
can emit or omit at whim.

And with that writing 'robust' code becomes impossible, as long as it
matters to you whether the a=0; statement will read back the volatile 'a' 
or not.


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