<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-10-20 23:28 GMT+02:00 Eliot Miranda <span dir="ltr">&lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 1:35 PM, Esteban Lorenzano <span dir="ltr">&lt;<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>&gt;</span> wrote:<br><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><div style="word-wrap:break-word">well… I solve the problem. <div>Everything is about the first issue report (comparison is always true). </div><div>I changed first from “unsigned long” to “sqLong” but then I realised sqLong is defined as “long long” so this expression: </div><div><br></div><div><span style="white-space:pre-wrap">        </span>intValue bitXor: (intValue &lt;&lt; 1)) &gt;= 0</div><div><br></div><div>since number fitted in &quot;long long”, was also always true. Then of course it was converting into a SmallInteger a number that should be a LongPositiveInteger. </div><div><br></div><div>my fix: just to change #maybeInlinePositive32BitIntegerFor: and around to ensure parameter is “sqInt”. </div><div>That works. </div></div></blockquote><div><br></div><div>No, you can&#39;t cast within  maybeInlinePositive32BitIntegerFor:.  That will break its use on long long values.</div></div></div></div></blockquote><div><br></div><div>Hi Eliot,<br></div><div>but when would you pass unsigned long long &gt; 16rFFFFFFFFUL ?<br></div><div>In most case that would be positiveMachineIntegerFor: as you said...<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></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"><div style="word-wrap:break-word"><div><br></div><div>Now, I have this doubts: </div><div><br></div><div>- how is possible this was working before? maybe this is a change in clang 7 (apple)?</div></div></blockquote><div><br></div><div>Unless we look in the debugger we won&#39;t know.</div><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"><div style="word-wrap:break-word"><div>- now I have a lot of complains of “comparison of unsigned expression is always true” all around the image. Should we take care about them?</div></div></blockquote><div><br></div><div>Looks like it.</div><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"><div style="word-wrap:break-word"><div><br></div><div>I will do some tests and commit to VMMaker tomorrow. </div></div></blockquote><div><br></div><div>Don&#39;t just blindly commit a fix that makes clang 7 work.  It could easily break everything elsewhere.  Instead, we need to understand the issues first.</div><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"><div style="word-wrap:break-word"><div><br></div><div>cheers,</div><div>Esteban</div><div><br></div><div><br><div><blockquote type="cite"><div>On 19 Oct 2015, at 18:31, Esteban Lorenzano &lt;<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><div>Hi, </div><div><br></div><div>Does anyone tested Alien on Spur and &quot;El capitan&quot;? specifically callbacks?</div><div>For me, a completely broken :(</div><div><br></div><div>1) this structure (in maybeInlinePositive32BitIntegerFor: and others): </div><div><br></div><div><div><span style="white-space:pre-wrap">        </span>(integerValue &gt;= 0</div><div><span style="white-space:pre-wrap">        </span> and: [objectMemory isIntegerValue: integerValue]) ifTrue:</div><div><span style="white-space:pre-wrap">                </span>[^objectMemory integerObjectOf: integerValue].</div></div><div><br></div><div>Does not works if “integer value” is an unsigned long, because compiler assumes it will always be true, then remove the if, then answers a wrong value. </div><div><br></div><div>2) <span style="color:rgb(120,73,42);font-family:Menlo;font-size:11px">assertCStackWellAligned </span>always fail. No idea why because if does not says anything, just jmp back to the regular flow. </div><div><br></div><div>3) finally, <span style="color:rgb(79,129,135);font-family:Menlo;font-size:11px">ceCaptureCStackPointers </span>also fails… this can be because (2) or because other reasons (it also jmps back so no clue) (method generateCaptureCStackPointers: clarifies is a hack, so I suppose it stopped to work). </div><div><br></div><div>I guess solution of (1) is easy: argument number just has to be a sqLong instead an unsigned long. </div><div><br></div><div>But for 2 and 3 I have no idea where to start.</div><div><br></div><div>Does anyone has an idea?</div><div><br></div><div>Esteban</div><div><br></div></div></div></blockquote></div><br></div></div><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
<br></blockquote></div><br></div></div>