This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlinedastrees
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Jason Merrill <jason at redhat dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 16 Dec 2001 10:00:48 -0800 (PST)
- Subject: Re: Volatile MEMs in statement expressions and functions inlinedastrees
On Sun, 16 Dec 2001, Linus Torvalds wrote:
>
> Every statement-expression decays to a rvalue.
Well duh, THAT was obviously easily shown to be completely bogus.
6.2.1 explicitly says that the standard conversions are not applied to
expressions in expression statements.
Which probably means that gcc right now is in violation of THAT when it
does
volatile int i;
main()
{
i;
}
because right now gcc _does_ dereference "i", even though it's an lvalue.
That means one of two things:
- the dereference has nothing to do with "lvalue->rvalue conversion".
- or Richard was wrong in calling this "implementation defined
behaviour", and gcc is buggy here.
To some degree this actually makes me "happier" about it: one of the main
inconsistencies I pointed out in my early postings was exactly the
inconsistency between accesses in the statements
i;
i = 0;
In both cases the value is thrown away, and in both cases the statement is
an lvalue. Yet in the first case gcc will do the access regardless of
whether the value is used or not - while in the second case gcc will only
do the "read" if the value is unused.
I tried to fix that inconsistency by getting rid of the read in the second
case.
But not doing the read in the first case when the value is discarded is
also consistent.
So which is it?
- "lvalue->rvalue conversion is NOT the same as 'access' when evaluating
the expression"
- "gcc is currently buggy because it _does_ do the access even though
the standard says no lvalue->rvalue conversion takes place".
I think you can choose one or the other, but not both.
(And if you choose the first one, then we're really back to square one,
because one of the arguments _for_ re-reading the value was because of the
rvalue conversion. If the rvalue conversion is not a dereference when
evaluating the expression, then there is no reason to do the dereference
after the assignment).
Linus