<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hello,</div><div><br></div><div>Can you check whether your build includes r358547?<br><br>Thanks,<br></div><div><br></div><div>Dan</div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 8, 2019 at 5:33 AM Carlo Kok via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>It's a wasm testcase that ends up with a 1 mb executable; after 15 minutes I killed it, it doesn't do anything (note that it's waiting on a conditional variable in ALL threads)<br></div><div><br></div><div>On Wed, May 8, 2019, at 14:32, Brian Cain wrote:<br></div><blockquote type="cite" id="gmail-m_-6200708349872850533gmail-m_3732506938165861182qt"><div dir="auto"><div>Are you sure it's not just taking "a long time"? If that build machine doesn't have enormous amounts of memory you could end up with a link phase that takes tons of time for projects like clang or chrome. <br></div><div dir="auto"><br></div><div dir="auto">Try linking a minimal case. If the bug you describe were there it should reproduce easily (maybe once you get up to enough object files or sections, whatever it's iterating over). <br></div></div><div><br></div><div class="gmail-m_-6200708349872850533gmail-m_3732506938165861182qt-gmail_quote"><div class="gmail-m_-6200708349872850533gmail-m_3732506938165861182qt-gmail_attr" dir="ltr">On Wed, May 8, 2019, 7:25 AM Carlo Kok via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail-m_-6200708349872850533gmail-m_3732506938165861182qt-gmail_quote"><div>On a 12" MacBook (2017) with 2 cores I get lld/wasm to be stuck in:<br></div><div> <br></div><div> <a rel="noreferrer noreferrer" href="https://gist.githubusercontent.com/carlokok/1a14e7ed3dbbd54511e1f0b3a7d684ff/raw/19267560b584ca42cc66f44f508df5b34102d803/thread%2520for%2520waiting" target="_blank">https://gist.githubusercontent.com/carlokok/1a14e7ed3dbbd54511e1f0b3a7d684ff/raw/19267560b584ca42cc66f44f508df5b34102d803/thread%2520for%2520waiting</a><br></div><div> <br></div><div> It seems the outer for loop exhausts the thread pool, and the inner ones trigger a new parallel for which never finishes because the pool is full. Is this a bug or am I missing something obvious?<br></div><div> <br></div><div> <br></div><div> --<br></div><div> Carlo Kok<br></div><div> _______________________________________________<br></div><div> LLVM Developers mailing list<br></div><div> <a rel="noreferrer" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br></div><div> <a rel="noreferrer noreferrer" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div></blockquote><div><br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>