Pauli via llvm-dev
2016-Nov-05 16:57 UTC
[llvm-dev] llvm-toolchain-3.8 on lower arm targets
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>
Sylvestre Ledru via llvm-dev
2016-Nov-13 12:34 UTC
[llvm-dev] Bug#820535: llvm-toolchain-3.8 on lower arm targets
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! Thanks S
Emilio Pozuelo Monfort via llvm-dev
2016-Nov-22 20:21 UTC
[llvm-dev] llvm-toolchain-3.8 on lower arm targets
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