similar to: [LLVMdev] AArch64 build error

Hi Paul, > I'm getting a "random" build failure related to AArch64 when building with cmake. > The build is running with -j32 so it seems that there is some dependency issue > that causes the build to fail when things build in a certain order. > 3008 make[2]: *** No rule to make target `lib/Target/AArch64/AArch64GenDAGISel.inc', needed by Hmm. That file's

Hi everyone. I'm seeing a sporadic failure in building the AArch64 backend when doing a parallel make from CMake-generated Unix makefiles: + (cd "$WORKSPACE/llvm/build" && cmake -G "Unix Makefiles" \ -DCMAKE_C_COMPILER="$TOOLCHAIN/usr/bin/clang" \ -DCMAKE_CXX_COMPILER="$TOOLCHAIN/usr/bin/clang++" \

Hi Tim, On 2013-05-17 4:18 PM, "Tim Northover" <t.p.northover at gmail.com> wrote: >Hi Paul, > >> I'm getting a "random" build failure related to AArch64 when building >>with cmake. >> The build is running with -j32 so it seems that there is some >>dependency issue >> that causes the build to fail when things build in a certain

Am 01.11.2011 18:04, schrieb Joerg Sonnenberger: > On Tue, Nov 01, 2011 at 11:09:41AM +0100, Joachim Durchholz wrote: >> On the reasons why make-based builds are slow, Peter Miller has some >> insight to offer: >> http://miller.emu.id.au/pmiller/books/rmch/ . >> I'm not sure how widely recognized that paper is. Maybe it's widely >> known and today's

Dear All, We have a new 32 core machine, so I ran some numbers. These results are for compiling all of LLVM and Clang in a Debug build from scratch. The first number is the -j argument to make, and the rest is the result of the bash builtin time command. 2: 1612.950u 161.293s 15:04.92 196.0% 0+0k 0+0io 0pf+0w 4: 1624.101u 164.121s 8:00.74 371.9% 0+0k 0+0io 0pf+0w 8:

Hello John. John Criswell <criswell at illinois.edu> writes: [snip] > I did not use CMake but the standard autoconf + Makefile build. > > Not sure if this helps, but here it is, for what it's worth. Very interesting, thanks! CMake introduces more parallelism and it would be great to see how much impact it makes. If you can, please run the cmake build with -j32, just to

Hi r-users,   I have the following code to solve 4 simultaneous eqns with 4 unknowns using newton iteration method.  But I got the error message:   pars <- c(1.15, 40, 50, 0.78) newton.input2 <- function(pars) {  ## parameters to estimate      alp <- pars[1]    b1  <- pars[2]     b2  <- pars[3]    rho <- pars[4]   f1 <- pars[1]*pars[2] f2 <-

Hi there, I initially asked about this on r-help and was told this might be a better venue. I?m not really convinced from reading the posting guide, but I?ll give it a shot. It was also suggested that the R-Project doesn?t really care about building with ?non-standard? compilers, but I can?t find any evidence of that on the website (indeed, there?s some mention of successful past builds, and the

On 04/02/2014 10:32 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 02, 2014 at 09:27:29AM -0400, Waiman Long wrote: >> N.B. Sorry for the duplicate. This patch series were resent as the >> original one was rejected by the vger.kernel.org list server >> due to long header. There is no change in content. >> >> v7->v8: >> - Remove one unneeded

On 04/02/2014 10:32 AM, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 02, 2014 at 09:27:29AM -0400, Waiman Long wrote: >> N.B. Sorry for the duplicate. This patch series were resent as the >> original one was rejected by the vger.kernel.org list server >> due to long header. There is no change in content. >> >> v7->v8: >> - Remove one unneeded

On Wed, Apr 02, 2014 at 10:10:17PM -0400, Waiman Long wrote: > On 04/02/2014 04:35 PM, Waiman Long wrote: > >On 04/02/2014 10:32 AM, Konrad Rzeszutek Wilk wrote: > >>On Wed, Apr 02, 2014 at 09:27:29AM -0400, Waiman Long wrote: > >>>N.B. Sorry for the duplicate. This patch series were resent as the > >>> original one was rejected by the vger.kernel.org

On Wed, Apr 02, 2014 at 10:10:17PM -0400, Waiman Long wrote: > On 04/02/2014 04:35 PM, Waiman Long wrote: > >On 04/02/2014 10:32 AM, Konrad Rzeszutek Wilk wrote: > >>On Wed, Apr 02, 2014 at 09:27:29AM -0400, Waiman Long wrote: > >>>N.B. Sorry for the duplicate. This patch series were resent as the > >>> original one was rejected by the vger.kernel.org

On Fri, May 24, 2013 at 3:27 PM, Kyle Holzinger <kholz at bu.edu> wrote: > So I just started looking into LLVM and I was wondering how to install the > LLVM tools suite. (Such as the llvm-as or lli commands in the terminal > described here: http://llvm.org/docs/CommandGuide). I have downloaded > LLVM, Clang, the test suite, and have run the build and make commands. I > have

So I just started looking into LLVM and I was wondering how to install the LLVM tools suite. (Such as the llvm-as or lli commands in the terminal described here: http://llvm.org/docs/CommandGuide (http://llvm.org/docs/CommandGuide/)). I have downloaded LLVM, Clang, the test suite, and have run the build and make commands. I have looked around on the website but I have not found a sufficient

Hi all: Unable to install libvirt v5.5.0 correctly through the source code which clone from git. The error message is shown below. libtool: install: (cd /home/libvirt/src; /bin/sh /home/libvirt/libtool --silent --tag CC --mode=relink gcc -std=gnu99 -I/usr/include/libxml2 -fno-common -W -Waddress -Waggressive-loop-optimizations -Wall -Wattributes -Wbad-function-cast -Wbuiltin-macro-redefined

On Fri, Apr 04, 2014 at 01:13:17PM -0400, Waiman Long wrote: > On 04/04/2014 12:55 PM, Konrad Rzeszutek Wilk wrote: > >On Thu, Apr 03, 2014 at 10:57:18PM -0400, Waiman Long wrote: > >>On 04/03/2014 01:23 PM, Konrad Rzeszutek Wilk wrote: > >>>On Wed, Apr 02, 2014 at 10:10:17PM -0400, Waiman Long wrote: > >>>>On 04/02/2014 04:35 PM, Waiman Long wrote:

On Fri, Apr 04, 2014 at 01:13:17PM -0400, Waiman Long wrote: > On 04/04/2014 12:55 PM, Konrad Rzeszutek Wilk wrote: > >On Thu, Apr 03, 2014 at 10:57:18PM -0400, Waiman Long wrote: > >>On 04/03/2014 01:23 PM, Konrad Rzeszutek Wilk wrote: > >>>On Wed, Apr 02, 2014 at 10:10:17PM -0400, Waiman Long wrote: > >>>>On 04/02/2014 04:35 PM, Waiman Long wrote:

On Thu, Apr 17, 2014 at 6:10 PM, Yaron Keren <yaron.keren at gmail.com> wrote: > If accuracy is not critical, incrementing the counters without any guards > might be good enough. > No. Contention on the counters leads to 5x-10x slowdown. This is never good enough. --kcc Hot areas will still be hot and cold areas will not be affected. > > Yaron > > > >

Hi, The current design of -fprofile-instr-generate has the same fundamental flaw as the old gcc's gcov instrumentation: it has contention on counters. A trivial synthetic test case was described here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066116.html For the problem to appear we need to have a hot function that is simultaneously executed by multiple threads -- then we will

I did a sanity check and run some of the bitcode I complied with gllvm and it seems to work fine under lli. The only issues is to make sure you load all the (external) libraries the bitcode needs. I highly suggest you run a debug version of lli under a debugger and see what exactly happens. On Mon, Jan 28, 2019 at 12:45 PM Peng Yu <pengyu.ut at gmail.com> wrote: > It seems that it does