[PATCH][RFC] Remove volatile from data members in libstdc++
Andrew Haley
aph@redhat.com
Tue Jul 18 17:58:00 GMT 2006
Martin Sebor writes:
> Boehm, Hans wrote:
> >>From: Richard Guenther [mailto:rguenther@suse.de]
> >>
> >>I believe gcc at the moment won't do it, but of course from
> >>the standards point of view it is permittet to treat local
> >>just like global inside the function. And indeed volatile
> >>guarantees you a single access of global here - though it is
> >>sufficient to make the access volatile and not the data, like in
> >>
> >> unsigned local = *(volatile unsigned *)&global;
> >>
> [...]
> >
> > I agree that a volatile cast for the read is just as good.
>
> Sorry to jump in on this, but just as an FYI, there is at least one
> compiler where the cast doesn't have the same effect (i.e., the
> compiler takes into account the volatility of the object in the
> cast) and that, we were told by the compiler vendor, is a feature
> and not a bug.
My understanding is that volatility belongs to the object, so a
compiler might do that. But it would be a Bad Thing, and we know
we're using gcc, and we hope gcc doesn't do that.
> I realize that's unrelated to gcc or the problem in rope but I
> think it's interesting to note that different implementers have
> different interpretations of what volatile should mean even in
> seemingly straightforward cases like this one.
In this case I suspect it's more to do with quality of implementation
than correctness: the compiler has been told volatile, and it's a
foolhardy compiler that throws volatile away...
Andrew.
More information about the Gcc-patches
mailing list