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

[Pauli via llvm-dev]

On Wed, 5 Oct 2016 23:33:49 +1300, Bruce Hoult wrote:
> 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.

Attached patch to debian libstdc++ package is supposed to fix clang
compilation.I'm still waiting compilation to complete before I can
test it. The compilation will take long time in an armel vm. I decided
to share it in case someone else has faster test environment than I
have.

The patch has extra src directory that needs to be striped with
s/\([ab]\)\/src/\1/g if someone tries to apply it to upstream sources.

Pauli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libstdc++-fix-future-header-for-armel.patch
Type: text/x-patch
Size: 6578 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161105/e7e972e5/attachment.bin>