------- Additional Comments From schlie at comcast dot net 2005-05-21 20:48
-------
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > This is undefined, see the full discussion on the gcc list:
> > > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html
> >
> > - out of curiosity, it's not clear that the discussion reached any
> > conclusion which enables GCC to disreguard the type semantics
> > as specifed by the program code. Where in the standard does it
> > specify that a type qualifier may be disreguarded if convenient?
>
> See http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html
Thanks for the reference, I reviewed it and agree, but not for the reason
stated. It has nothing to do with the declared type of the object, as a
volatile qualified lvalue reference requires the object be accessed as
a volatile, but may be fully optimized away iff it can be "deduced" that
its omission would have no effect on the program's behavior.
This was only reasonable to "deduce" because the objects address was not
itself a literal address, or assigned to a volatile reference either directly or
indirectly through a potential alias (as doing so would have extended the
visibility of the object beyond the program itself, thereby requiring that the
specified volatile access semantics be retained).
In other words, in the following program variants, the specified volatile
access could not have been optimized away:
---
int avail;
(volatile int *)0x0123 = &avail; // because it's value is now potentially
// modifiable external to the program.
int main() {
while (*(volatile int *)&avail == 0)
continue;
return 0;
}
---
int *avail = (int *)0x0ABC; // as above, it's allocated location isn't
private.
int main() {
while (*(volatile int *)avail == 0)
continue;
return 0;
}
---
Thanks, If this is what GCC formally does, it would be nice to see it
documented?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
