This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: volatile [was: GCC warnings for unused global variables]
- From: Bernd Jendrissek <berndj at prism dot co dot za>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Michael Eager <eager at eagercon dot com>, Fergus Henderson <fjh at cs dot mu dot OZ dot AU>, Richard Henderson <rth at redhat dot com>, Geoff Keating <geoffk at geoffk dot org>, jbuck at synopsys dot com, espie at quatramaran dot ens dot fr, gcc at gcc dot gnu dot org
- Date: Wed, 7 May 2003 11:33:21 +0200
- Subject: Re: volatile [was: GCC warnings for unused global variables]
- References: <or1xzbh08y.fsf@free.redhat.lsd.ic.unicamp.br>
On Wed, May 07, 2003 at 06:03:09AM +0200, Alexandre Oliva wrote:
> On May 7, 2003, Michael Eager <eager@eagercon.com> wrote:
>
> > If you take the view that "a <op>= b" involves a read and a write,
> then
> > translating it into load/operate/store is correct.
>
> But then, so is a single instruction that loads, operates then stores,
> right? The thing is that GCC doesn't ever give such instruction a
> chance if the variable is volatile.
The biggest difference I can see being that a single instruction can be
made "more" atomic than a sequence can: you can add a lock prefix to the
*single* instruction, so that *no other bus master* can access your
volatile variable while it is being manipulated.
Maybe GCC should sometime in the distant future tack some "volatile"
attribute onto match_operand's or maybe even add VQI, VHI, VSI, etc. so
that the machine description can capture more information about the
achievable volatile-safety that it can support? But then, you'd need
a cleaner error message than "ICE blah blah unmatched instr". So that
if you have
volatile int a;
a *= argfoo;
and the machine doesn't have a multiplication instruction, the compiler
can barf so you can *know* that your code assumes things it shouldn't.
But how best to get this information into machine descriptions without
simply duplicating it all?