This is the mail archive of the
mailing list for the GCC project.
Re: -fno-tree-cselim not working?
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.
> So: accesses to any variable read or written
> whilst protected by a lock are ordered with respect
> to any other accesses protected by a lock in any
> other thread, whether or not the variable is aliased
> or volatile.
> I'm deducing this from existing practice NOT any standards:
> in this circumstance, volatile is NOT needed.
That is correct: it's not needed if there is a lock, access, unlock
sequence. In the example which started this brouhaha, there was no
> That leaves open several questions. One is: what can
> we say about a write in thread A *prior* to a lock
> being set and released, and a read in thread B
> *after* a lock is set and released, where the read
> is certain to be following the write temporaly,
> for a variable NOT accessed during the exclusion period
> by either thread?
A correct mutex implementation is required to use compiler specific
magic to implement a memory barrier. In gcc, this magic is implement
via an inline asm. This memory barrier will impose the natural
> 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.
> [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.