similar to: liblldCommon is broken at head

Displaying 20 results from an estimated 500 matches similar to: "liblldCommon is broken at head"

2019 Mar 19
2
Building lld
I tried deleting my build directory and restarting from scratch $ cd llvm-project $ mkdir build && cd build $ cmake -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS=lld ../llvm $ make I got this error: make[2]: *** No rule to make target 'llvm/cmake/modules/GenerateVersionFromVCS.cmake', needed by 'tools/lld/Common/VCSVersion.inc'. Stop. CMakeFiles/Makefile2:57166:
2019 Mar 20
3
Building lld
Judging by this path: needed by 'tools/lld/Common/VCSVersion.inc' It looks to me like this is **not** a monorepo layout (if it were, lld would not appear in the tools directory). Therefore the LLVM_ENABLE_PROJECTS=lld is not even doing anything. I don't know how to build without a monorepo these days, and I also don't know what the most recent guidance setting up a monorepo is,
2020 Mar 28
2
LLD issue on a massively parallel build machine
Hi, My configuration is below: cmake -GNinja -DLLVM_ENABLE_LLD=ON -DLLVM_ENABLE_THREADS=OFF -DLLVM_ENABLE_LIBCXX=ON -DCMAKE_BUILD_TYPE=Release -DGCC_INSTALL_PREFIX=/home/usr4/c74014i/opt/gcc-7.5.0/ -DLIBOMPTARGET_ENABLE_DEBUG=ON -DCMAKE_INSTALL_PREFIX=$HOME/opt/clang/${today} -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="" -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS=""
2020 Mar 28
3
LLD issue on a massively parallel build machine
$ free -g total used free shared buff/cache available Mem: 376 149 20 1 207 225 Swap: 3 0 3 Too small swap size for a 72-core login machine? On Sun, Mar 29, 2020 at 4:28 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Enable threads is for building llvm with
2020 Mar 28
2
LLD issue on a massively parallel build machine
That is slowing down the build visibly, for the speed I should stick with ld at the moment. On Sun, Mar 29, 2020 at 4:42 AM Alexandre Ganea <alexandre.ganea at ubisoft.com> wrote: > Would `taskset -c 0-3 ninja check-all -j4` work? > > > > *De :* Itaru Kitayama <itaru.kitayama at gmail.com> > *Envoyé :* March 28, 2020 3:37 PM > *À :* Alex Brachet-Mialot
2020 Mar 28
2
LLD issue on a massively parallel build machine
Good news, I was able to use up to 37 cores for LLVM build with LLD. The build speed, did not measure precisely though, is comparable to the build with GNU ld case. Thank you all for your help! On Sun, Mar 29, 2020 at 5:04 AM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: > Yes unfortunately that would limit you to 4 cores. > > There’s no easy way to use lld with
2020 Apr 01
4
LLD issue on a massively parallel build machine
On 2020-03-29, Nemanja Ivanovic via llvm-dev wrote: >Glad you got it working. >My suggestion about LLVM_ENABLE_THREADS didn't work because you didn't >apply it when building the build linker. > >When you don't have the ability to rebuild the build compiler, this doesn't >apply. In those cases, I end up doing a dirty hack where I use a wrapper >script with
2020 Apr 01
2
LLD issue on a massively parallel build machine
On 04/01/2020 01:47 PM, Itaru Kitayama via llvm-dev wrote: > Thanks for the heads up the supercomputer > Is down for maintenance this week. > I’ll give it a try when it gets back. > This doesn't look to me like it's necessarily an lld issue. Trying to build all the sub-projects without limiting the number of ninja jobs is almost guaranteed to run out of memory on a machine
2020 Mar 18
2
Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration
Hi Folks, Commit ac1d23ed7de01fb3a18b340536842a419b504d86 introduces a change in the way CodeGen and MC CommandFlags are handled. It's a change that may impact some devs, so I'd better give a small notice here. Basically previous approach was to bundle all options in a .inc file that declares a bunch of llvm::cl options. This file was lying in include/llvm and was to be included in
2020 Apr 01
2
LLD issue on a massively parallel build machine
On another login node which is 256 (GB)/48 (nodes) JURECA at JSC, I never had an LLD issue without setting -j when executing ninja in the past few weeks. On Thu, Apr 2, 2020 at 7:17 AM Itaru Kitayama <itaru.kitayama at gmail.com> wrote: > Tom, > Then what ratio do you think it’s minimal? > > On Thu, Apr 2, 2020 at 6:11 Tom Stellard <tstellar at redhat.com> wrote: >
2019 Mar 13
2
Building lld
I tried to build lld by following these steps: https://lld.llvm.org/getting_started.html But after 'make install' I can't find lld anywhere and 'make check-lld' results in this message: make: *** No rule to make target 'check-lld'. Stop. Any idea? -------------- next part -------------- An HTML attachment was scrubbed... URL:
2020 Mar 28
3
LLD issue on a massively parallel build machine
Alex : Can you please try `numactl` or `taskset` after https://github.com/llvm/llvm-project/commit/09158252f777c2e2f06a86b154c44abcbcf9bb74 ? There was a tiny bug in how sched_getaffinity() was used, see: https://reviews.llvm.org/D75153#1942336 De : Alex Brachet-Mialot <alexbrachetmialot at gmail.com> Envoyé : March 28, 2020 12:11 PM À : Itaru Kitayama <itaru.kitayama at gmail.com>
2017 Dec 21
5
llc: Unknown command line argument '-debug-only=isel'
Hi LLVM developers, llc -march=mips -debug-only=isel was able to work in Nov 8 2017 https://reviews.llvm.org/D39723 But it doesn't work now: $ clang --version LLVM China clang version 6.0.0 (git at github.com:llvm-mirror/clang.git 9b7b03045ee9b5622028537266aafeb9ea218ac1) (git at github.com:llvm-mirror/llvm.git 3a26601a88394c02603b8756527c55df9ab94d78) (based on LLVM 6.0.0svn) Target:
2017 Dec 01
3
gnu X sysv hash performance
I got curious how the lld produced gnu hash tables compared to gold. To test that I timed "perf record ninja check-llvm" (just the lit run) in a BUILD_SHARED_LIBS build. The performance was almost identical, so I decided to try sysv versus gnu (both produced by lld). The results are interesting: % grep -v '^#' perf-gnu/perf.report-by-dso-sym | head 38.77% ld-2.24.so
2017 Dec 21
3
llc: Unknown command line argument '-debug-only=isel'
-debug-only only works on builds with assertions enabled. Your version string says optimized build and doesn’t mention assertions. On Thu, Dec 21, 2017 at 7:15 AM Leslie Zhai via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi LLVM developers, > > llc -march=mips -debug-only=isel was able to work in Nov 8 2017 > https://reviews.llvm.org/D39723 > > But it doesn't
2017 Aug 06
2
Compile issues with LLVM ORC JIT
I tree to compile the LLVM ORC JIT examples. But I'm stuck in some problems I can't solve my own. First at all I compile with C++14 enabled with latest stable LLVM and clang, this means 4.0.1. I get the following error. Do I missed some specific compile option? Compilation looks like this here. |CompilingcontribJIT.cpp PWD:/home/ikuehl/projects-llvm/TurboLisp/domainEngineer
2017 Nov 17
2
HTML documentation is not in the expected location
Since I have updated my Linux system, and consequently re-installed R, I am unable to see HTML documentation which I used to access via a web browser. To be more specific, my R installation is declared to be here: > R RHOME /usr/local/lib/R However, if I look at a location such as /usr/local/lib/R/library/base/html this contains only two entries File: 00Index.html File: R.css
2018 Jun 08
2
Fail to install llvm/clang on debian
Hello, Maybe this is not a bugs. But i fail to install llvm many times and different machine(debian os). First, i follow the instruction: http://cilium.readthedocs.io/en/latest/bpf/#llvm But during in compiling, i alway get: ... /home/yubo/git/llvm/tools/clang/lib/Basic/VirtualFileSystem.cpp: In member function ‘virtual llvm::ErrorOr<std::unique_ptr<clang::vfs::File> >
2008 Mar 19
1
adimpro package : R does not seem to find my ImageMagick installation
Dear list, (sorry if I post to the wrong place...), Though having spent some time on it, I cannot find an answer by myself to the following behaviour of the read.image function (adimpro package) : I'm running R.2.6.2 on Windows XP. The home directory is C:\Program files\R\R-2.6.2 Version 0.4.4 of adimpro is loaded. ImageMagick 6.3.0 is installed, its directory is C:\Program
2020 May 08
2
blockcommit --pivot does not succeed in conjunction with qemu 5.0.0
Hello one and all. Got a problem with libvirt 6.2.0 and qemu 5.0.0. virsh blockcommit mymachine vda --active --verbose --pivot works until it shows [100%] but it never actually pivots. It just sits there. Is this a known issue with 6.2.0 and i should try 6.3.0? For now i switched back to qemu 4.2.0 and this seems to solve the issue too. Any hints? Ahoi! t.