similar to: [LLVMdev] Difference in behavior between local machine and buildbot

*[qali at qali llvm-2.8-rev]$ find . -exec grep -n "LLVMCC_EMITIR_FLAG" ./ {} \;* ./projects/test-suite/Makefile.tests:47: -$(LCC) $(CPPFLAGS) $(CFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG) ./projects/test-suite/Makefile.tests:51: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG)

On Jan 15, 2011, at 8:06 PM, Qingan Li wrote: > [qali at qali llvm-2.8-rev]$ find . -exec grep -n "LLVMCC_EMITIR_FLAG" ./ {} \; > ./projects/test-suite/Makefile.tests:47: -$(LCC) $(CPPFLAGS) $(CFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S $< -o $@ $(LLVMCC_EMITIR_FLAG) > ./projects/test-suite/Makefile.tests:51: -$(LCXX) $(CPPFLAGS) $(CXXFLAGS) $(LOPTFLAGS) $(X_TARGET_FLAGS) -S

*1. I have searched the access/setting of LLVMCC_EMITIR_FLAG in the build directory, recursively, and all the output is what I pasted in last email (just the same to the that in source directory). Maybe the configure failed to do it. My command list for building the test suit is as followings:* *(1) cd ~/SRC_DIR/llvm/projects* *(2) svn co http://llvm.org/svn/llvm-project/test-suite/trunk

On Jan 13, 2011, at 6:22 PM, Qingan Li wrote: > make[4]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE' > /home/qali/Src/llvm-2.8/autoconf/mkinstalldirs Output > /dev/null > /home/qali/build/llvm-gcc4.2-2.8-x86_64-linux/bin/llvm-gcc -I/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource/UnitTests/Vector/SSE

---------- Forwarded message ---------- From: Qingan Li <ww345ww at gmail.com> Date: 2011/1/19 Subject: Re: [LLVMdev] About test suits Cont1 To: Eric Christopher <echristo at apple.com> *I am sorry for making you confused when I presented my problem.* *1. My steps for the test suit building:* (1) cd /home/qali/Src; * // This is my source directory for all application

[qali at qali test-suite]$ make VERBOSE=1 if [ ! -f SingleSource/Makefile ]; \ then \ /home/qali/Src/llvm-2.8/autoconf/mkinstalldirs SingleSource; \ cp /home/qali/Src/llvm-2.8/projects/test-suite/SingleSource/Makefile SingleSource/Makefile; \ fi; \ make -C SingleSource all make[1]: Entering directory `/home/qali/build/llvm-2.8-rev/projects/test-suite/SingleSource' if [ ! -f UnitTests/Makefile

All, This buildbot is getting lots of assertion failures in the test suite. They were probably caused by my commit: ------------------------------------------------------------------------ r151049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines Changed paths: M /llvm/trunk/lib/VMCore/LLVMContextImpl.h M /llvm/trunk/lib/VMCore/Type.cpp PR1210: make uniquing of struct and

On Tue, Feb 21, 2012 at 2:51 AM, Jay Foad <jay.foad at gmail.com> wrote: > All, > > This buildbot is getting lots of assertion failures in the test suite. > They were probably caused by my commit: > > ------------------------------------------------------------------------ > r151049 | foad | 2012-02-21 09:25:52 +0000 (Tue, 21 Feb 2012) | 6 lines > Changed paths: >

All the LLVM lab FNT builders were reporting failures in the same set of tests (scimark2, LivermooreLoops, some others). Now they've all turned green but the same tests are still failing. I don't see any commits to deliberately make the FNT pass, so it looks like someone broke failure detection... Note that the FNT "report" text became empty at the same time. Here's what

This issue is back: FNT bots are reporting success in spite of tests failing, and the "report" text is empty again. Did someone change something? Ciao, Duncan. On 12/12/12 07:53, Duncan Sands wrote: > On 11/12/12 23:16, Galina Kistanova wrote: >> The problem remains after the buildmaster restart. > > The FNT builders are now all failing again, and the "report"

On Tue, Dec 11, 2012 at 1:27 AM, Duncan Sands <baldrick at free.fr> wrote: > All the LLVM lab FNT builders were reporting failures in the same set of > tests > (scimark2, LivermooreLoops, some others). Now they've all turned green but > the > same tests are still failing. I don't see any commits to deliberately make > the > FNT pass, so it looks like someone

On 11/12/12 23:16, Galina Kistanova wrote: > The problem remains after the buildmaster restart. The FNT builders are now all failing again, and the "report" is no longer empty. Does anyone know what fixed them? Ciao, Duncan. > > Thanks > > Galina > > > > -----Original Message----- > From: David Blaikie [mailto:dblaikie at gmail.com] > Sent: Tuesday,

The problem remains after the buildmaster restart. Thanks Galina -----Original Message----- From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Tuesday, December 11, 2012 11:42 AM To: Galina Kistanova Cc: Duncan Sands; llvm-lab-wg at lists.minormatter.com; Galina Kistanova; llvmdev at cs.uiuc.edu Subject: Re: [llvm-lab-wg] FNT testers reporting success even though they failed On Tue,

On Tue, Dec 11, 2012 at 11:40 AM, Galina Kistanova <gkistanova at accesssoftek.com> wrote: > Hello everyone, > > It might make sense to start from rebooting the buildmaster, just to make sure everything is all right on this end. > Yesterday I have tried to apply the latest changes from zorg and some of them are broken. > Theoretically, checkconfig shouldn't affect the

Hello everyone, It might make sense to start from rebooting the buildmaster, just to make sure everything is all right on this end. Yesterday I have tried to apply the latest changes from zorg and some of them are broken. Theoretically, checkconfig shouldn't affect the working instance, but the reality could be different... I planned to rollback to the last known-to-be-good revision and

Hi Renato, I've investigated a few of these for AArch64 recently, and some of the results will be applicable in the 32-bit world too. > MultiSource/Benchmarks/McCat/12-IOtest/iotest.execution_time This is because of disagreement between ABIs over whether "char" is signed. ARM says no, x86 says yes. >

Having worked with optim() and related programs for years, it surprised me that I haven't noticed this before, but optim() is inconsistent in how it deals with bounds constraints specified at infinity. Here's an example: # optim-glitch-Ex.R x0<-c(1,2,3,4) fnt <- function(x, fscale=10){ yy <- length(x):1 val <- sum((yy*x)^2)*fscale } grt <- function(x, fscale=10){ nn

On Tue, Jan 8, 2013 at 1:40 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 8 January 2013 04:49, Duncan Sands <baldrick at free.fr> wrote: >> >> While this should be investigated, >> I'm tempted to just move everything over to LNT instead... > > > That's the latent bugs that David mentioned. I agree we should have LNT and > LNT+LTO

Hi Folks, Looks like our LNT ARM buildbot with the vectorizer is running and producing good results. There are only 11 failures: FAIL: MultiSource/Applications/Burg/burg.execution_time (1 of 1104) FAIL: MultiSource/Applications/ClamAV/clamscan.execution_time (2 of 1104) FAIL: MultiSource/Applications/lemon/lemon.execution_time (3 of 1104) FAIL:

Hello together, perhabs anyone of you, has an ideal, how i can do this: I have a matrix, like this one: [,1] [,2] [,3] [,4] abnr2 11425 11425 11555 11888 TIME 2 1 1 2 Cat 1 2 1