<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thanks renato I will try to do this but it is quite difficult for me, I don’t known a lot about llvm project, not more than wikipedia definition ;-)</div><div class="">I had a look on ARMFatsISel source file history. In 2012 a change concerning “support for non-global callee” has removed a guard condition in SelectCall method.</div><div class=""><<<a href="https://github.com/llvm-mirror/llvm/commit/1c8fccbc12e6348c8003aff9b89078324257fc4e" class="">https://github.com/llvm-mirror/llvm/commit/1c8fccbc12e6348c8003aff9b89078324257fc4e</a>>></div><div class=""><br class=""></div><div class=""><div class=""> // Only handle global variable Callees.</div><div class="">const GlobalValue *GV = dyn_cast<GlobalValue>(Callee);</div><div class="">if (!GV)</div><div class=""> return false;</div></div><div class=""><br class=""></div><div class="">I restored this peace of code in my local llvm source code, rebuild rust and … no more blx instruction generated, all my run programs seems to run correctly !</div><div class="">I’m sure it is not a solution but it could help to solve/understand the issue.</div><div class=""><br class=""></div><div class="">Have a nice we.</div><div class=""><br class=""></div><div class="">Frédéric.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 11 Sep 2015, at 13:43, Renato Golin <<a href="mailto:renato.golin@linaro.org" class="">renato.golin@linaro.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On 11 September 2015 at 12:41, Frédéric Richez <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class="">I’m using rust head version that currently use llvm 3.7 …<br class=""></blockquote><br class="">Yes, I saw that, tracking the GitHub repo relatively closely.<br class=""><br class="">I also thought about that v4 bug on the same area from 3.6, but this<br class="">seems to be a new one.<br class=""><br class="">I think the best thing to do now is to create a bugzilla entry with as<br class="">much information as you can. If possible, try to reduce to a piece of<br class="">IR that reproduces the failure with standard tools. If not, the more<br class="">you can provide the better, so at least we can help you debug the<br class="">problem.<br class=""><br class="">cheers,<br class="">--renato<br class=""></div></blockquote></div><br class=""></body></html>