This is the mail archive of the
mailing list for the GCC project.
Re: -fno-tree-cselim not working?
On Fri, 2007-10-26 at 07:58 -0700, Ian Lance Taylor wrote:
> skaller <firstname.lastname@example.org> writes:
> > As I understand it volatile is typically used as a 'hint'
> > to the compiler that there could be aliases it cannot see.
> > This is independent of the use suggesting asynchronous changes
> > in a hardware port for example, although the effect is the same.
> Not really. Volatile has a reasonably precise definition: it means
> that memory accesses must be done precisely as they are written in the
> program. They may not be coalesced, and they may not be moved.
I understand that's the common meaning .. but the semantics
aren't specified for ISO C/C++.
> > And in effect that means ALL variables must be synchronised,
> > unless the compiler is exceedingly smart!
> No, it means that the implementation of mutex must be magic.
Same thing isn't it?
> > [BTW I think this sucks, the need to synchronise ALL memory
> > on mutexing is far too heavy]
> It can not be avoided, for the reasons you describe.
Of course it can be avoided easily if the memory model
allowed for local synchronisation sets, so the real problem
appears to be that Posix doesn't provide proper synchronisation
I guess that's why 'volatile' appears attractive: one *might*
say that accesses to volatiles are atomic and ordered, without
implying anything about other memory (I'm not suggesting that,
just commenting that it would provide a way to reduce synchronisation
burden). I.e. a volatile variable acts as a kind of 'port' between
threads which act like 'processes'.
In fact, volatiles mapped onto hardware registers fronting async
devices really ARE doing just that.
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net