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 inlined as trees
On 23-Dec-2001, Linus Torvalds <torvalds@transmeta.com> wrote:
>
> 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.
>From a QOI perspective, I think lcc does a far better job than gcc,
because it issues a warning.
> 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.
I understand your argument here, but I think you are way overstating your case.
The letter of the law for volatile is essentially implementation-defined,
> > 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.
"What constitutes an access to an object that has volatile-qualified type is
implementation-defined." That seems pretty clear to me.
An implementation could say that *nothing* constitutes access to an
object of volatile-qualified type, and could then entirely ignore
volatile (except in as far as type checking and the effects on
setjmp()/longjmp() are concerned).
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.