<div dir="ltr"><div dir="ltr"><div>Follow-up:</div><div><br></div><div>I tried to generate empty function rather than broken function:</div><div><br></div><div><a href="http://source.squeak.org/VMMaker/VMMaker.oscog-nice.2577.diff">http://source.squeak.org/VMMaker/VMMaker.oscog-nice.2577.diff</a></div><div><br></div><div>This failed because the non local return did result in such generated code:</div><div><br></div><div>        return result;</div><div>        return 0;</div><div>    }</div><div><br></div><div>So I tried to remove the function entirely:</div><div><div><br></div><div><a href="http://source.squeak.org/VMMaker/VMMaker.oscog-nice.2578.diff">http://source.squeak.org/VMMaker/VMMaker.oscog-nice.2578.diff</a></div></div><div><br></div><div>This failed, because the function is used (that's why it was not eliminated):</div><div><br></div><div><a href="https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/609457879">https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/609457879</a></div><div><pre id="gmail-log" class="gmail-ansi"><div class="gmail-log-line"><span id="gmail-0-2637">Undefined symbols for architecture x86_64:</span></div></pre><pre id="gmail-log" class="gmail-ansi"><div class="gmail-log-line"><span id="gmail-0-2638">  "_genSendDirectedSupernumArgs", referenced from:</span></div></pre><pre id="gmail-log" class="gmail-ansi"><div class="gmail-log-line"><span id="gmail-0-2639">      _genExtSendSuperBytecode in cogit.o</span></div></pre><pre id="gmail-log" class="gmail-ansi"><div class="gmail-log-line"><span id="gmail-0-2640">ld: symbol(s) not found for architecture x86_64</span></div></pre><pre id="gmail-log" class="gmail-ansi"><div class="gmail-log-line"><span id="gmail-0-2641">clang: error: linker command failed with exit code 1 (use -v to see invocation)</span></div></pre><pre id="gmail-log" class="gmail-ansi"><div class="gmail-log-line"><span id="gmail-0-2642">make: *** [build/vm/NewspeakVirtualMachine] Error 1</span><span id="gmail-0-2643"></span></div></pre><pre id="gmail-log" class="gmail-ansi"><span id="gmail-0-2644" class="gmail-red gmail-bold">The command "$CHROOT ./scripts/ci/travis_build.sh" failed and exited with 1 during .</span><span id="gmail-0-2645"></span></pre></div></div><div>Of course, I should have seen it in Smalltalk:</div><div>genExtSendSuperBytecode<br>           "239               11101111        i i i i i j j j Send To Superclass Literal Selector #iiiii (+ Extend A * 32) with jjj (+ Extend B * 8) Arguments"<br>            | isDirected litIndex nArgs |<br>     (isDirected := extB >= 64) ifTrue:<br></div><div>    ...snip...<br></div><div>            ^isDirected <br>        ifTrue: [self genSendDirectedSuper: litIndex numArgs: nArgs]<br>                     ifFalse: [...</div><div><br></div><div>And this is used in NewspeakV4 bytecode set too:</div><div>initializeBytecodeTableForNewspeakV4</div><div>        ...snip...<br></div><div>                       (2 239 239 genExtSendSuperBytecode isMapped)</div><div><br></div><div>Funnily (sadly?), when I removed the generation of genDirectedSuper:numArgs: send, the generator started to generate the (now unused) global scope variables!</div><div><br></div><div><a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e2027f4941b64d5713a97fb95c64eef63ef3f48a">https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e2027f4941b64d5713a97fb95c64eef63ef3f48a</a></div><div><br></div><div>My conclusion is:<br></div><div>- NewspeakV4 includes a bytecode that potentially generate directed super send</div><div>- but BytecodeSetHasDirectedSuperSend is set to false in Newspeak flavor</div><div>- this mismatch lead to incorrect code generation.</div><div><br></div><div>Shouldn't we set BytecodeSetHasDirectedSuperSend := true for NewspeakV4?</div><div>I'm going to try...<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 29 oct. 2019 à 00:57, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
On Mon, Oct 28, 2019 at 10:52:38PM +0100, Nicolas Cellier wrote:<br>
>  <br>
> Hi David,<br>
> OK, the variables are initialized conditionally in Cogit>>setInterpreter:<br>
> <br>
>      BytecodeSetHasDirectedSuperSend ifTrue:<br>
>          [directedSuperSendTrampolines := CArrayAccessor on: (Array new:<br>
> NumSendTrampolines).<br>
>          directedSuperBindingSendTrampolines := CArrayAccessor on: (Array<br>
> new: NumSendTrampolines).<br>
>          directedSendUsesBinding := false].<br>
> <br>
<br>
There is a <doNotGenerate> directive for the method, so the initialization<br>
that you see there is never part of the generated C code.<br>
<br>
<br>
> So maybe it's not the case of Newspeak bytecode set, and maybe these<br>
> methods won't be used, but it's not a nice way to do it.<br>
> We shall not generate unused incorrect methods, it spoils compiler warning<br>
> examination...<br>
><br>
<br>
Actually, I think that it /is/ used (or at least it could be used if<br>
#isDirected is true, which probably amounts to the same thing). All of<br>
the unreferenced methods will be optimized away by the inliner, but there<br>
is one remaining usage, and it does look like a possible source of trouble.<br>
<br>
Dave<br>
<br>
<br>
> Le dim. 27 oct. 2019 ?? 19:58, David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> a ??crit :<br>
> <br>
> ><br>
> > On Sat, Oct 26, 2019 at 11:45:08PM +0200, Nicolas Cellier wrote:<br>
> > ><br>
> > > Hi all,<br>
> > > I see what looks like a big problem in those files:<br>
> > ><br>
> > <a href="https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/nsspur64src/vm/cogitX64SysV.c" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/nsspur64src/vm/cogitX64SysV.c</a><br>
> > ><br>
> > <a href="https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/nsspursrc/vm/cogitIA32.c" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/nsspursrc/vm/cogitIA32.c</a><br>
> > ><br>
> > > The generated code for genSendDirectedSuper:numArgs: is bogus.<br>
> > > the 3 instance variables<br>
> > > - directedSendUsesBinding<br>
> > > - directedSuperSendTrampolines<br>
> > > - directedSuperBindingSendTrampolines<br>
> > > have been translated into local (thus uninitialized) variables...<br>
> > ><br>
> > > How can this possibly work?<br>
> > > Is it related to the CI failures?<br>
> ><br>
> > Very likely the variables are being generated as local because they are<br>
> > not referenced elsewhere. For example, directedSuperSendTrampolines is<br>
> > initialized in simulation only by Cogit>>setInterpreter: but apparently<br>
> > is not set anywhere in the actual translated code.<br>
> ><br>
> > I don't think that uninitialized locals are set to null in C, so yes<br>
> > this could be a source of random behavior in the CI tests.<br>
> ><br>
> > A solution would be to initialize the three variables, possibly just<br>
> > by referencing them explicitly in one of the declareCVarsIn: methods.<br>
> ><br>
> > Dave<br>
> ><br>
> ><br>
<br>
</blockquote></div></div>