This is the mail archive of the gcc-bugs@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]

access to a volatile variable


> 
> Alexandre Oliva wrote:
> > 
> > On Jun 17, 1999, Nathan Sidwell <nathan@acm.org> wrote:
> 
> > > though we probably want to warn about such volatile accesses.
> > 
> > What's the point?  I'd agree with warning about volatile accesses of
> > built-in types, such as `*(int*)foo', since they'd just be optimized
> > away (would they?), but it doesn't make sense to access a volatile
> > struct as a whole, does it?
> Oops yes, the incompleteness is irrelevant, it's the volatileness which is
> important.
> 
> volatile int *pvi;
> struct foobar;
> volatile foobar *pvfb;
> foobar *pfb;
> 
> int x;
> x = *pvi; //access through pointer
> *pfb = *pvfb; // error, dereference incomplete
> *pvfb; // no error, no deref -- should warn (this construct doesn't make much
> sense even if complete)
> *pvi; //no access - should warn
> 
> [better check this last case does result in us not generating an access, but
> that's a different potential bug report]

If you are writing code that the volatile element is a memory mapped 
I/O channel, this construct makes sense.  Just because you don't do 
anything with the result you read from the I/O channel doesn't mean that 
strobing the address bus to access a volatile will have no affect.

David


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