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

		Linus


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