This is the mail archive of the gcc-patches@gcc.gnu.org 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 15, 2001, Linus Torvalds <torvalds@transmeta.com> wrote:

> See the four points above. They are perfectly consistent.

I agree.  They are self-consistent, and, AFAICT, they are in agreement
with the text of the C++ Standard.  The problem I'm trying to deal
with is that there is this other reading, that Jason was able to
explain much better than myself (thanks, Jason!), that makes even more
sense to me, even though it's not the semantics that would be most
well-suited in case of chains of assignments involving volatile
lvalues, especially ones contained in memory mapped devices' memory.


Unfortunately, taking Jason's reading may take us a few step backs, to
a question that I think you (Linus) first raised.  Consider the
following chunks of C++ code:

volatile int i, *p = &i, &r = i;
//... {
  i;

Do we want the value stored in i to be read by this expression
statement?  Why should we read it?  i by itself is an lvalue, why
should it decay to an rvalue, requiring an access (as it appears that
we have agreement that lvalue-to-rvalue involves an access, except in
the case of the lvalue resulting from an assignment).  And how about:

  *p;
  r;

Same argument here, slightly different spelling.  Clearly (to me), it
shouldn't make any difference whether the lvalue is obtained by means
of naming a variable or a pointer or reference that happens to refer
to it.

And how about:

  (void&)i;
  
  (i, *p, r);

  (void)i;  (void)*p;  (void)r;

Note that the GCC extension that makes the result of a cast be an
lvalue may interfere with the behavior of the last line above.  But I
don't know whether the extension applies to C++ too.  It certainly has
different semantics from that of simply casting to an lvalue of
another type, as already seen in this thread.


Now that we've covered simple expressions, let's move on to
assignments:

  *p = i;

Here, the result of the assignment is an lvalue.  Should the
expression statements above involve an access to the lvalue, why
shouldn't this?  But it appears to me that we don't want this one to
do a read after the store, whereas we may want the first three to do
so.


Just to mud waters a little further, consider:

inline volatile int& f() { return i; }
//... {
  f();

Should the reference to `i' by itself access the contents of the
variable, would we get an access as part of the execution of f() too?
Or would the fact that the variable is only used as an lvalue, as
opposed to not being used at all or being used as an rvalue, make a
difference?  And would the lvalue returned by f() be accessed?


The other outstanding issue is whether a statement expression (a GCC
extension) can every result in an lvalue.  It appears to me that it
would be perfectly reasonable to say they can't, period.  Any
disagreement here?


> I'm claiming that we _are_ actually accessing the lvalue. We're trivially
> accessing it by _writing_, not by reading. The standard doesn't say what
> really constitutes an "access", so you might as well say that "writing the
> value is a form of access that modifies the lvalue and returns the value
> stored".

I like this idea very much.  It would be an excellent way to solve the
problem, but unfortunately it is not consistent with the reading
proposed by Jason.  The C++ Standard says ``the result of an
assignment operation is the value contained [in the original, stored]
in the left operand *after* the assignment has taken place; the result
is an lvalue.''  Note, it's not ``at the time of the assignment'',
it's ``after the assignment has taken place''.  So, the atomic
write&prentend-to-read :-) operation cannot be used for the access
involved in a standard lvalue-to-rvalue conversion.

This is so unfortunate :-(

-- 
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


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