Bug#820535: llvm-toolchain-3.8 on lower arm targets

Sylvestre Ledru sylvestre at mozilla.com
Sun Nov 13 12:34:31 UTC 2016

Le 05/11/2016 à 17:57, Pauli a écrit :
> 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.
Doko, any chance you could apply this patch?
This would be great for armel!


More information about the Pkg-llvm-team mailing list