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: 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
be evaluated.


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