[llvm-dev] llvm-toolchain-3.8 on lower arm targets

[Bruce Hoult via llvm-dev]

On Wed, Oct 5, 2016 at 7:46 AM, Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Emilio,
>
> On 4 October 2016 at 11:14, Emilio Pozuelo Monfort via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > In file included from /«PKGBUILDDIR»/lib/Support/ThreadPool.cpp:14:0:
> > /«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h: In member function
> > 'std::shared_future<void> llvm::ThreadPool::async(Function&&, Args&&
> ...)':
> > /«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h:78:77: error: return
> type
> > 'class std::shared_future<void>' is incomplete
> >    inline std::shared_future<VoidTy> async(Function &&F, Args &&...
> ArgList) {
> >
>     ^
> >
> > Any idea about this failure?
> >
> > For the Debian armel porters, we're switching to LLVM 3.8, so this
> failure
> > (which happens on 3.8, 3.9 and llvm-toolchain-snapshot) is likely going
> to cause
> > some package removals on armel as we try to get rid of older LLVM
> versions.
> > Helping fixing this issue would be appreciated to prevent that.
>
> This looks like the kind of failure you get when your host toolchain
> doesn't support C++11 properly (specifically lock-free atomics in this
> case).  When I've seen it before GCC was defaulting to a CPU that's
> too old to do atomics properly, and that configuration is very
> unlikely to be supported by LLVM ever (any more).
>

This seems bogus.

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.

If you don't call atomic_is_lock_free(&var) then everything should work
correctly, albeit perhaps more slowly than you might like.

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!

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161005/e371eb9d/attachment.html>