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


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