<div dir="ltr"><div class="gmail_extra" style>Hey Scott,</div><div class="gmail_extra" style><br></div><div class="gmail_extra">On Wed, Apr 24, 2013 at 1:40 PM, Scott Pakin <span dir="ltr"><<a href="mailto:pakin@lanl.gov" target="_blank">pakin@lanl.gov</a>></span> wrote:<br>
<div class="gmail_quote"><div>... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Is there some semantic reason that the increments aren't allowed to be<br>
combined, or is this a missed optimization opportunity in LLVM?<br><br></blockquote><div><br></div><div style>I believe that the wildcard is the extern keyword.</div><div style><br></div><div style>Since the external symbol isn't resolved until link time, I suspect that it would be a legal C program to do something like (maybe the language lawyers know better though):</div>
<div style><br></div><div style><div>XXX> cat test.c</div><div>extern int x;</div><div><br></div><div>int kung( ) {</div><div>  return x;</div><div>} </div><div><br></div><div>XXX> cat foo.c</div><div><div>extern int kung();</div>
<div><br></div><div>volatile int x;</div><div><br></div><div>int main() {</div><div>  x = 0;</div><div>  return kung();</div><div>}</div></div><div><br></div><div style>Ugly programming, but I see no way of the linker having enough information to determine that the extern should be volatile and issue an warning/error.</div>
<div style><br></div><div style>One more reason to use explicit barriers instead of volatile. ;)</div><div style><br></div><div style>-Cameron</div></div></div></div></div>