<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 8, 2015 at 7:54 PM, Ryan Macnak <span dir="ltr"><<a href="mailto:rmacnak@gmail.com" target="_blank">rmacnak@gmail.com</a>></span> wrote:<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 Sun, Jun 7, 2015 at 8:58 AM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></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"><div><div><br>
<br>
On 07-06-2015, at 12:32 AM, Holger Freyther <<a href="mailto:holger@freyther.de" target="_blank">holger@freyther.de</a>> wrote:<br>
>> On 07 Jun 2015, at 01:25, tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>> wrote:<br>
>><br>
>><br>
>> GCC is such fun.<br>
><br>
> given the amount of warnings emitted during compilation, have you considered<br>
> that it might be the input given to gcc that is the issue here? ;)<br>
<br>
</div></div>I dunno; I get a total of 59 warnings when compiling the ARM Cog VM, none in the core vm code. I’d love to see it be 0. I rather suspect the world would come to an end if that happened.<br>
<br>
On the other hand, I can’t see how it is acceptable for a compiler to produce code that blows up at one level of optimisation but not at another. Come to that I’m not sure why there are different levels; I can sort of see asking to optimise in different ways - the NorCroft compiler for ARM can be asked to optimise for runtime speed or executable size, for example.<br></blockquote><div><br></div><div>I'm inclined to believe Cog is relying on undefined behavior somewhere, and this isn't gcc's fault. I've not built functional Newspeak VMs on modern compilers since ~1317, but this overlaps with the VM being broken on old compilers for other reasons so I haven't figured out what change is responsible.</div></div></div></div></blockquote><div><br></div><div>Hi Ryan,</div><div><br></div><div> IMO the likely issue is register usage in trampoline calls. The JIT tries to reduce register saving and restoring across trampoline calls by using a notion of the ABI's caller-saved registers. Callee-saved registers shouldn't be an issue because either a run-time call returns to the same trampoline that invoked it, hence restoring callee-saved registers, or enters machine code via an enlopmart which assumes no registers are live and restores any and all registers as appropriate. But there could be bugs here, and certainly gcc could change over versions, perhaps becoming more aggressive in register saving, and surfacing previously undetected bugs here.</div><div><br></div><div>One thing to do is compare a StackInterpreter VM against Cog, at least to locate the blame. Then, if the finger does point at the Cogit, to locate the issue after setting up a reproducible case, run with some kind of tracing (e.g. each message selector, but the Cogit could straight-forwardly add tracing to the trampolines) to see what the VM is doing immediately before the crash.</div></div><br>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>