This is the mail archive of the
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlined as trees
On Thu, Dec 13, 2001 at 12:25:45PM -0800, Linus Torvalds wrote:
> - A lvalue as part of an expression (ie _not_ as the left side of an
> argument) is always converted to a rvalue, whether that rvalue is
> actually used or not.
This I do not agree with.
> See also existing gcc practice, see the example of code generated
> for just a plain "p" when "p" is volatile.
Plain "p" is implementation defined, based on the fact that the
definition of what constitutes an "access" to a volatile quantity
is implementation defined.
GCC has defined that as an access for volatiles only. This because
it is useful to generate a read from a volatile memory and ignore the
results. Otherwise you'd be forced to write "tmp = p".
> This is not meant as a
> "proof", but it _is_ clearly an indication that other parts of gcc
> (and most programmers) certainly think that the lvalue->rvalue
> conversion always happens, whether the rvalue is used or not.
That g++ currently generates an extra load from "p = 0;" is simply an
indication that no one has touched the volatile loading code in ages;
probably since before c++ standardized the result of operator= being
an lvalue. It is most definitely not a consious decision.
As an aside, I don't think the C++ definition is useful -- I much prefer
how chained assignment may be interpreted in C -- but I also think that
Jason has correctly interpreted how C++ forces the chained assignment to