<html>
<head>
<base href="http://bugzilla.gdcproject.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126#c24">Comment # 24</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - Add support for attribute to mark data as volatile."
href="http://bugzilla.gdcproject.org/show_bug.cgi?id=126">bug 126</a>
from <span class="vcard"><a class="email" href="mailto:ibuclaw@gdcproject.org" title="Iain Buclaw <ibuclaw@gdcproject.org>"> <span class="fn">Iain Buclaw</span></a>
</span></b>
<pre>(In reply to Jens Bauer from <a href="show_bug.cgi?id=126#c23">comment #23</a>)
<span class="quote">> (In reply to Johannes Pfau from <a href="show_bug.cgi?id=126#c22">comment #22</a>)
> > 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 ?</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>