This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Remove volatile from data members in libstdc++
- From: Andrew Haley <aph at redhat dot com>
- To: Martin Sebor <sebor at roguewave dot com>
- Cc: "Boehm, Hans" <hans dot boehm at hp dot com>, Richard Guenther <rguenther at suse dot de>, Ian Lance Taylor <iant at google dot com>, Paolo Carlini <pcarlini at suse dot de>, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Tue, 18 Jul 2006 18:45:32 +0100
- Subject: Re: [PATCH][RFC] Remove volatile from data members in libstdc++
- References: <65953E8166311641A685BDF71D865826C1E3EC@cacexc12.americas.cpqcorp.net> <44BD1C60.3030804@roguewave.com>
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.