This is the mail archive of the
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlined astrees
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 7 Dec 2001 09:57:16 -0800 (PST)
- Subject: Re: Volatile MEMs in statement expressions and functions inlined astrees
On Fri, 7 Dec 2001, Jason Merrill wrote:
> I would agree with that interpretation, were it not for the lvalue bit.
> Indeed, my point is that that's the difference between C and C++.
Actually, I can _guarantee_ that my reading of the standard is correct.
Proof: if your reading of the standard is correct, then the statement
volatile int p;
p = 0;
should always generate a store _and_ a load.
Why? According to the C standard the expression "p = 0" will return a
value whether that return value is _used_ or not. There is no provision
for "..only if used".
And very clearly we do NOT want the simple statement to generate a load,
nobody in his right mind will argue that for C _or_ for C++.
Ergo, if you do
q = p = 0;
then the fact that you assign "q" clearly MUST NOT change the behaviour of
the independent expression that assigns "p". The expression "p = 0" is
_unchanged_ by the fact that we assign the value to "q", and anybody who
claims differently is out to lunch.
So having thought it over, I will now claim that the current behaviour of
gcc is clearly a bug, and that there is no ambiguity in either C or C++.
Obviously, bug or not, depending on the exact behaviour of "volatile" in C
(or C++) is asking for trouble, it's just too badly defined. I think gcc
might as well really be aggressive and honour the letter of the standard
and only consider "volatile" to be meaningful at sequence points.