This is the mail archive of the 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 as trees

On 23-Dec-2001, Linus Torvalds <> 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 <>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <>  |     -- the last words of T. S. Garp.

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