<div class="gmail_quote">On Wed, Jun 24, 2009 at 9:06 PM, Vesa Karvonen <span dir="ltr">&lt;<a href="mailto:vesa.a.j.k@gmail.com">vesa.a.j.k@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">&gt; MLton 20061107 works. So does 20070826.</div></div></blockquote><div><br>Strange that this didn&#39;t used to happen.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="h5">Did you try this on a x86 platform? </div></div></blockquote><div><br>This was only on x86, yes.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="h5">If so, did you try with -ieee-fp true?</div></div></blockquote><div><br>With this flag it terminates.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="h5"> Here is my theory.  On x86, the<br></div></div>
print in the loop has the effect of forcing the y&#39; value out of FP<br>
registers.  This allows the loop to terminate.  Otherwise, with the<br>
80-bit registers of the x86, and the 80-bit value of y&#39; in a register<br>
at the time of the comparison, the loop will never terminate as the<br>
64-bit value of y and the 80-bit value of y&#39; will never be equal.</blockquote><div><br></div></div>Actually it seems the two 80-bit values never become equal:<br> loop_12:<br>        fldL (globalReal64+0x8)<br>        fldL 0x30(%ebp)<br>
        fdivr %st, %st(1)<br>        fadd %st, %st(1)<br>        fxch %st(1)<br>        fdivL (globalReal64+0x0)<br>        fxch %st(1)<br>        fucomp %st(1)<br>        fnstsw %ax<br>        andw $0x4500,%ax<br>        cmpw $0x4000,%ax<br>
        je L_1331<br>L_151:<br>        fstpL 0x30(%ebp)<br>        jmp loop_12<br><br>The comparison is indeed happening in a floating point register, which means it might behave differently than when truncated in/out of memory for the C call.<br>
<br>