This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
access to a volatile variable
- To: nathan at cs dot bris dot ac dot uk
- Subject: access to a volatile variable
- From: David Whitten <whitten at netcom dot com>
- Date: Thu, 17 Jun 1999 09:19:16 -0700 (PDT)
- Cc: egcs-bugs at egcs dot cygnus dot com
>
> 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