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 astrees

On Dec 16, 2001, Linus Torvalds <> 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.


> 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

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
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist    *Please* write to mailing lists, not to me

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