Re: Volatile MEMs in statement expressions and functions inlined astrees

[Alexandre Oliva <aoliva at redhat dot com>]

On Dec 16, 2001, Linus Torvalds <torvalds@transmeta.com> wrote:

> For example, right now we have the issue that an assignment to a volatile
> value will have _different_ semantics depending on non-local effects
> around that assignment.

[snip]

> The way _I_ expect things to work, it should not _matter_ whether a value
> is used or not. The side effects of that expression take place, and the
> value is either discarded or not.

So do you say that, in the following chunk of code:

volatile int i;

volatile int& f() { return i; }

i should be dereferenced, even though all we want is a reference to
it?

If you step back on this one, you're admitting that you can't just say
`every lvalue always decays to rvalue, be it by using the value last
assigned to it, be it by accessing it' for C++ in general.  If you
support it, I think we're going to have serious problems.  If you want
to go back from C++ to C, consider:

volatile int i;

volatile int *f() { return &i; }

Now, at a certain moment, we have an `i' lvalue, whose rvalue is never
used.  All we do with this lvalue is take its address.  Should we
still load the value of `i', just for the sake of the consistency and
the uniformity you're looking for?  I don't think so.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me