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

[Emilio Pozuelo Monfort via llvm-dev]

On 05/11/16 17:57, Pauli wrote:
> 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.

Did you have a chance to test it?

Cheers,
Emilio