<div dir="ltr"><div style>You mean the boolan in `Escaping`?</div><div><br></div>I am not an expert on the hipe compiler, but I just had<div style>a look at the code and I think I have some answers.</div><div style><br></div>
<div style>`Escaping` is  the functions that can be called from<br></div><div style>outside the module (they presumably needs stubs).</div><div style>The boolean seems to be `true` for funs and `false`</div><div style>for exports.</div>
<div style><br></div><div style>But the boolean is not actually used!</div><div style>hipe_icode_coordinator filters it away! (See</div><div style>coordinate/4 and initialize_server/2.)</div><div style><br></div><div style>
I have attached a crude fix that eliminates the</div><div style>duplicate entry in `Escaping`. I have verified that</div><div style>the compiler no long hangs, but I have not verified</div><div style>anything else.</div><div style>
<br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 10:09 AM, Anthony Ramine <span dir="ltr"><<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kostis,<br>
<br>
My patch removes the automatic eta-abstraction for function references from the BEAM code generation [1]. The consequence of this is that some fun references labels (the ones which are from exported functions) are now taken from the exports table in beam_dict.<br>

<br>
This makes hipe pass exported functions which are used as fun references to hipe_coordinator both in `Closures` and `Exported`, and that makes everything hang if the exported function contains a fun reference to itself, like in erl_syntax:is_literal/1 [3].<br>

<br>
Could you explain to me what `Escaping` and `NonEscaping` means? More specifically, what the boolean() value in the pairs of `NonEscaping` mean.<br>
<br>
Regards,<br>
<br>
[1] <a href="https://github.com/nox/otp/commit/42b87b" target="_blank">https://github.com/nox/otp/commit/42b87b</a><br>
[2] <a href="https://github.com/nox/otp/blob/master/lib/hipe/main/hipe.erl#L762-770" target="_blank">https://github.com/nox/otp/blob/master/lib/hipe/main/hipe.erl#L762-770</a><br>
[3] <a href="https://github.com/nox/otp/blob/master/lib/syntax_tools/src/erl_syntax.erl#L5909-5929" target="_blank">https://github.com/nox/otp/blob/master/lib/syntax_tools/src/erl_syntax.erl#L5909-5929</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Anthony Ramine<br>
<br>
Le 20 janv. 2013 à 09:30, Kostis Sagonas a écrit :<br>
</font></span><div class="im HOEnZb"><br>
> The following is just a guess, but I suspect that your patch either broke a bytecode invariant that the hipe type analyzer relied on (in which case your code needs to respect this invariant), or generated code which is OK but it's code that had never been tested before (so it's a bug in the analysis of the native code compiler)<br>

<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Björn Gustavsson, Erlang/OTP, Ericsson AB
</div>