[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