Re: Volatile MEMs in statement expressions and functions inlined astrees

[Linus Torvalds <torvalds at transmeta dot com>]

On Sun, 23 Dec 2001, Fergus Henderson wrote:
>
> lcc is a C compiler only, not a C++ compiler, so your hypothesis is
> definitely wrong in the case of lcc.

Ok, let me just then say that in that case I think lcc is a bad compiler,
and while you can always fall back on the "volatile is not clearly
defined" argument for doing _anything_at_all_ (including playing
towers-of-hanoy whenever the compiler sees a "volatile"), I think the
situation is fairly clear from a Quality-of-Implementation side.

There is _absolutely_ NO excuse for thinking that the subexpression "p" is
different (in C) in the two statements

	p;
	i = p;

and anybody who claims different is just making things up.

The _only_ difference is that in one case the value of the expression is
used and in the other one it is thrown away, but the C standard _clearly_
says that accessing a volatile object is a "side effect" and cannot be
optimized away.

As such, optimizing away the access just because the value is not used is
a BUG.

In short, lcc is violating the spirit of "volatile", and I would claim
that it comes d*mn close to violating the letter of the law too.

> > So, put the three together:
> >
> >  - C semantics are clear: the expression "p" is _identical_ in both of
> >    the statements "p;" and "i = p;". It should thus behave the same way.
> >
> >  - C++ semantics are less clear, but gcc documentation implies that the
> >    access is _allowed_ by the standard, and the standard clearly does say
> >    that C++ semantics are _indended_ to be identical to C semantics.
> >
> > So what do you say?
>
> I think that in neither C nor C++ are the semantics clear.

Oh, the C semantics are very clear indeed, and you're just trying to save
face by advocating a standpoint that has absolutely no support in the
standard.

> For C, I think that if you define "what constitutes access to a volatile
> object" in the most obvious way, then the most natural interpretation
> is that "p;" would load "p",  However, I don't think the C standard
> mandates this.

You're making very untenable claims.

See 6.8.3: "Expression and null statements"

	Syntax
		expression-statement

		expression{\sub opt} ;

	Semantics

		The expression in an expression statement is evaluated as
		a void expression for its side effects.

Go read it yourself.

The standard _clearly_ states that the expression is _evaluated_ and
expressly says that it is evaluated for its side effects.

That means that the expression statement

	p;

is required to be (a) evaluated and (b) the side effects have to be done.
There are no "if the compiler so feels" statements anywhere in the
standard. It is very clear and unambiguos. Other places in the C standard
also explicitly say "a void expression shall be evaluated for its side
effects".

So the standard _clearly_ disallows the notion that "not used" means "not
evaluated". There is _no_ argument for saying that "because the value of
'p' is not used, the expression is not evaluated, and so value is not
read from the volatile 'p'".

Do you have _any_ argument that is in _any_ way supported by the standard
that says otherwise? I'm not talking about "touchy-feely" arguments that
say "I think", I'm asking for arguments that refute my argument that at
least for C there is absolutely _no_ question about the fact that "p;" is
evaluated (and "p" thus accessed) regardless of whether the expression is
then implicitly cast to "(void)" by virtue of being an expression
statement.

		Linus