<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 5, 2016 at 7:46 AM, Tim Northover via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.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">Hi Emilio,<br>
<br>
On 4 October 2016 at 11:14, Emilio Pozuelo Monfort via llvm-dev<br>
<span class="gmail-"><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> In file included from /«PKGBUILDDIR»/lib/Support/<wbr>ThreadPool.cpp:14:0:<br>
> /«PKGBUILDDIR»/include/llvm/<wbr>Support/ThreadPool.h: In member function<br>
> 'std::shared_future<void> llvm::ThreadPool::async(<wbr>Function&&, Args&& ...)':<br>
> /«PKGBUILDDIR»/include/llvm/<wbr>Support/ThreadPool.h:78:77: error: return type<br>
> 'class std::shared_future<void>' is incomplete<br>
>    inline std::shared_future<VoidTy> async(Function &&F, Args &&... ArgList) {<br>
>                                                                              ^<br>
><br>
> Any idea about this failure?<br>
><br>
> For the Debian armel porters, we're switching to LLVM 3.8, so this failure<br>
> (which happens on 3.8, 3.9 and llvm-toolchain-snapshot) is likely going to cause<br>
> some package removals on armel as we try to get rid of older LLVM versions.<br>
> Helping fixing this issue would be appreciated to prevent that.<br>
<br>
</span>This looks like the kind of failure you get when your host toolchain<br>
doesn't support C++11 properly (specifically lock-free atomics in this<br>
case).  When I've seen it before GCC was defaulting to a CPU that's<br>
too old to do atomics properly, and that configuration is very<br>
unlikely to be supported by LLVM ever (any more).<br></blockquote><div><br></div><div>This seems bogus.</div><div><br></div><div>C++11 allows atomic variables to be implemented using mutexes if the CPU doesn't support atomic operations on a given data type in some other way.</div><div><br></div><div>If you don't call atomic_is_lock_free(&var) then everything should work correctly, albeit perhaps more slowly than you might like.</div><div><br></div><div>It seems to me that atomic_is_lock_free() (or precomputed shortcuts such as ATOMIC_INT_LOCK_FREE) is there to enable you the possibility to use a different algorithm (if one is available), not to throw up your hands and say you don't support that architecture at all!</div><div><br></div><div>If it's the standard library going out of its way to check ATOMIC_INT_LOCK_FREE  and then throwing up its hands and giving up then I'd say that's a bug. Simply taking out that check should produce working, correct code on anything that supports mutexes at all.</div><div><br></div></div></div></div>