<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-21 2:41 GMT+02:00 Andres Valloud <span dir="ltr"><<a href="mailto:avalloud@smalltalk.comcastbiz.net" target="_blank">avalloud@smalltalk.comcastbiz.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Or better: eliminate Undefined Behavior which is most probably the<br>
cause of problems<br>
</blockquote>
<br></span>
This is a good start for a default debugging procedure.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
Note: i've successfully compiled Squeak stack spur 64 bits with gcc<br>
4.9.2 -02 and restored the correct behavior for SmallFloat:<br>
2.0*3.0 correctly answer 6.0 instead of 4.0...<br>
<br></span><span class="">
Why is memcpy less evil than pointer aliasing?<br>
With pointer aliasing any other write into a long integer could modify<br>
doubleResult.<br>
This completely defeat optimization - the holy grail of C people, they<br>
can't bother that FORTRAN compilers are faster than theirs ;). With<br>
great wisdom they declared this construct as undefined behavior, giving<br>
priority to optimization rather than backward compatibility or<br>
programmers' intentions...<br>
memcpy is less evil because it's localized (one shot).<br>
</span></blockquote>
<br>
The GCC manual warns of potential issues with memcpy(), and recommends using unions instead. The union method worked on every HPS compilation environment, across multiple optimization levels. Whenever I checked, the resulting assembly code was optimal.<br>
<br>
<a href="https://gcc.gnu.org/bugs/#casting_and_optimization" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugs/#casting_and_optimization</a><br>
<br>
<a href="http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html" rel="noreferrer" target="_blank">http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html</a><span class=""><font color="#888888"><br>
<br>
Andres.<br></font></span></blockquote><div><br></div><div>Thanks Andres.<br><br></div><div>The problem you cite about memcpy is because it might be defined as a macro, and this restrict the possible constructs indeed<br>(No #if directive into macros in some old versions of compilers).<br></div><div>For VMMaker this is not a problem yet.<br>If it would be, we would see a compiler error, and would then workaround by rephrasing the slang and avoiding such construct...<br></div><div>A compiler error is a lot easier to fix than an invisibly stricking UB answering the unexpected result.<br></div><div><br></div><div>The usage of union for type-punning is indeed authorized and well defined - at least in C99.<br></div><div>But it has been controversial.<br></div><div>See <a href="http://stackoverflow.com/questions/11957450/is-this-a-proper-usage-of-union">http://stackoverflow.com/questions/11957450/is-this-a-proper-usage-of-union</a><br>and <a href="http://stackoverflow.com/questions/11639947/is-type-punning-through-a-union-unspecified-in-c99-and-has-it-become-specified">http://stackoverflow.com/questions/11639947/is-type-punning-through-a-union-unspecified-in-c99-and-has-it-become-specified</a><br>especially the arcane comments about interpretation of the standard !<br></div><div> <br></div><div>Cheers<br></div></div><br></div></div>