Comment # 24 on bug 126 from Iain Buclaw

(In reply to Jens Bauer from comment #23)
> (In reply to Johannes Pfau from comment #22)
> > The volatileLoad/Store intrinsics will have to suffice.
> 
> Are these guaranteed to be in the specified order for volatileLoad/Store,
> assuming a, b, c and d are different memory locations:
> 
>   read a
>   write b
>   read c
>   read d
> 
> -Or would the compiler be able to mess up the order ?

Compiler reordering should never mess up order of program logic to
variables/objects where changes are considered 'observable' (eg, on shared
data).  Most re-ordering/memoization happens on 'non-observable' data such as
local variables, thread-local storage.

However, that certainly doesn't stop certain C-like behaviours from occuring in
the optimiser.  Such include crash-inducing operations like divide by zero may
be pushed forward to occur before volatile load/reads or actions with
side-effects.