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

[Emilio Pozuelo Monfort via llvm-dev]

Hi Tim,

On 04/10/16 20:46, Tim Northover 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,

Oh, yeah. The std::shared_future reference ringed a bell in that direction. This
is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727621 FWIW.

> and that configuration is very
> unlikely to be supported by LLVM ever (any more).

Understandable.

> It looks like Debian may only support ARMv7 for armel anyway, in which
> case you should add something like "-march=armv7-a" to your C flags
> (-DCMAKE_C_FLAGS=-march=armv7-a and possibly
> -DCMAKE_CXX_FLAGS=-march=armv7-a too).

No, unfortunately armel on Debian targets armv4t, so we're out of luck. See the
above bug report. armhf targets armv7 IIRC, so that's why we don't hit this
issue there. Raspbian armel targets armv6, so that's why they are fine.

I guess this means no more LLVM on armel for now. For the next Debian release
(Buster) we'll have to see if we bump the minimum requirements on armel, or if
we drop the architecture entirely (at least as an official port).

Cheers,
Emilio