Re: Incrementing volatiles?

[Andreas Schwab <schwab at issan dot informatik dot uni-dortmund dot de>]

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

|> Andreas Schwab <schwab@issan.informatik.uni-dortmund.de> said:
|> > "Matthias Urlichs" <smurf@noris.de> writes:
|> > 
|> > |> Hi,
|> > |> 
|> > |> The following code, using egcs-current -O2 -fomit-frame-pointer
|> > |> 
|> > |>          unsigned int foo;    afoo() { foo++; }
|> > |> volatile unsigned int bar;    abar() { bar++; }
|> > |> 
|> > |>   compiles, on ix86, to
|> > |> 
|> > |> afoo:   incl foo
|> > |>         ret
|> > |> abar:   movl bar,%eax
|> > |>         incl %eax
|> > |>         movl %eax,bar
|> > |>         ret
|> > |> 
|> > |> But actually, it should be perfectly valid to compile both to code using
|> > |> "incr". After all, both versions read the variable, do something with it,
|> > |> and then write it out.
|> > |> 
|> > |> Is there a way to convince the optimizer to do this?
|> 
|> > No.  volatile prevents all attempts to combine instructions, because any
|> > two references to a volatile variable never match.  This is how gcc
|> > implements the implementation defined aspects of volatile.
|> 
|> Sorry if I'm being dense... I just don't see any difference here: both are
|> fetched, incremented and written back. And if it's "implementation defined",
|> gcc is free to optimize this, isn't it?

But that would be an awful special case.  All accesses to a volatile
variable must be exactly as specified by the user, which means that they
must never be moved, duplicated or combined.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org