<br><br><div class="gmail_quote">On Thu, Jul 21, 2011 at 3:17 PM, Stefan Marr <span dir="ltr"><<a href="mailto:squeak@stefan-marr.de">squeak@stefan-marr.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hi Eliot:<br>
<br>
On 21/07/11 19:35, Eliot Miranda wrote:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Thu, Jul 21, 2011 at 4:30 AM, David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a> <mailto:<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>>> wrote:<br>
<br>
<br>
<br>
Hi Eliot,<br>
<br>
Can you say what the issue was with signed32BitValueOf? I can<br>
see the changes in InterpreterPrimitives>><u></u>signed32BitValueOf:<br>
but I'm not clear on whether this is something that affects<br>
Alien, or if it is something that has been causing problems<br>
more generally but went unnoticed. Also, I'd like to document<br>
this with a unit test, so if you can suggest a code snippet<br>
that would be great.<br>
<br>
<br>
The unit test is in the lien tests and is the attempt to assign max neg int (-2^31) through signedLongAt:put:. The problem is due to a pervasive C compiler bug with optimization.<br>
</blockquote></div>
Maybe I misread this blog post: <a href="http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html" target="_blank">http://blog.llvm.org/2011/05/<u></u>what-every-c-programmer-<u></u>should-know.html</a> (*Signed integer overflow:)*<br>
but from that I would conclude that it is not a compiler bug, but undefined behavior in C instead. Thus, GCC and ICC are just doing there job in terms of what they are allowed to do by the spec.<br></blockquote><div><br>
</div><div>Thanks, Stefan. I hadn't known this (or had forgotten):</div><div><br></div><span class="Apple-style-span" style="font-family: 'Trebuchet MS', verdana, sans-serif; font-size: 13px; line-height: 22px; "><b id="signed_overflow">Signed integer overflow:</b> If arithmetic on an 'int' type (for example) overflows, the result is undefined. One example is that "INT_MAX+1" is not guaranteed to be INT_MIN. This behavior enables certain classes of optimizations that are important for some code. For example, knowing that INT_MAX+1 is undefined allows optimizing "X+1 > X" to "true". Knowing the multiplication "cannot" overflow (because doing so would be undefined) allows optimizing "X*2/2" to "X". While these may seem trivial, these sorts of things are commonly exposed by inlining and macro expansion. A more important optimization that this allows is for "<=" loops like this:<br>
<br><pre>for (i = 0; i <= N; ++i) { ... }
</pre><br></span><div><span class="Apple-style-span" style="font-family: 'Trebuchet MS', verdana, sans-serif; font-size: 13px; line-height: 22px; ">In this loop, the compiler can assume that the loop will iterate exactly N+1 times if "i" is undefined on overflow, which allows a broad range of loop optimizations to kick in. On the other hand, if the variable is defined to wrap around on overflow, then the compiler must assume that the loop is possibly infinite (which happens if N is INT_MAX) - which then disables these important loop optimizations. This particularly affects 64-bit platforms since so much code uses "int" as induction variables.</span></div>
<div><br></div><div><span class="Apple-style-span" style="font-family: 'Trebuchet MS', verdana, sans-serif; font-size: 13px; line-height: 22px; "></span>Makes evil sense :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Best regards<br><font color="#888888">
Stefan<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>best,<div>Eliot</div><br>