search for: fnt

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...

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 broke fa...

...From: llvm-lab-wg-bounces at lists.minormatter.com [mailto:llvm-lab-wg-bounces at lists.minormatter.com] On Behalf Of David Blaikie Sent: Tuesday, December 11, 2012 9:12 AM To: Duncan Sands Cc: 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, 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 gre...

...aster 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, 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. >...

...unces at lists.minormatter.com [mailto:llvm-lab-wg-bounces at lists.minormatter.com] On Behalf Of David Blaikie > Sent: Tuesday, December 11, 2012 9:12 AM > To: Duncan Sands > Cc: 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, 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&...

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. &gt...

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, December...

...64 Linux, I've checked out the same revision of llvm+clang+testsuite as the buildbot, I'm doing a Release+Asserts build. Is anyone else seeing these failures? Any ideas how I can reproduce them here? Thanks, Jay. Example failure from http://lab.llvm.org:8011/builders/clang-x86_64-debian-fnt/builds/4877/steps/make.test-suite/logs/stdio : 0 clang 0x0000000001e417ff 1 clang 0x0000000001e43a62 2 libpthread.so.0 0x00002aaaaacd9f60 3 libc.so.6 0x00002aaaab8cb165 gsignal + 53 4 libc.so.6 0x00002aaaab8cdf70 abort + 384 5 libc.so.6 0x00002aaaab8c42b...

...it is this patch. If so, we can keep experimenting with the patch, but it's important to get the builders back. There are several others seeing the failure as well. > > Thanks, > Jay. > > > Example failure from > > http://lab.llvm.org:8011/builders/clang-x86_64-debian-fnt/builds/4877/steps/make.test-suite/logs/stdio > : > > 0 clang 0x0000000001e417ff > 1 clang 0x0000000001e43a62 > 2 libpthread.so.0 0x00002aaaaacd9f60 > 3 libc.so.6 0x00002aaaab8cb165 gsignal + 53 > 4 libc.so.6 0x00002aaaab8cdf70 abort + 384 &g...

Hi I'm running the nightly test suite locally and getting a difference with the output from this buildbot (http://lab.llvm.org:8011/builders/clang-x86_64-debian-fnt/builds/1168/steps/make.test-suite/logs/stdio) For .ll tests the buildbot does the following (look for spirit.cpp in that link. Only comes up twice, one of which is this one) /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/llvm.obj/Release+Asserts/bin/clang++ ... -S /home/baldrick/osuosl/slave...

On 21 February 2012 11:45, Chandler Carruth <chandlerc at google.com> wrote: > Either way, I would try speculatively reverting to ensure it is this patch. > If so, we can keep experimenting with the patch, but it's important to get > the builders back. There are several others seeing the failure as well. OK, I've reverted it. Duncan is letting me play on the build slave

On Tue, Feb 21, 2012 at 4: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: >

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 <- length(x) yy <- nn:1 # gg <- rep(NA,nn) gg <- 2*(yy^2)*x*fscale gg } npar <- 4 lower <- -Inf l2 <- rep(-Inf,npar) a1 <- optim(x0, fn...

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

..., is to run only clang tests (check-all I presume) I'm confused. If it only runs check-all, why would we be migrating it to LNT? By the looks of it, the gcc12 slave is assigned to two builders. Picking a recent build from each: http://lab.llvm.org:8011/builders/dragonegg-x86_64-linux-gcc-4.6-fnt/builds/2147 http://lab.llvm.org:8011/builders/clang-x86_64-debian/builds/5723 The second is just a clang check-all on debian. That should probably remain untouched. The first is dragonegg 'fnt' AKA the test-suite or "nightly tests". This could be migrated to LNT. (FWIW: I tend...

Hello together, i have a data.frame, like this one: No. Change Date A 123 final 2013-01-15 B 123 error 2013-01-16 C 123 bug fixed 2013-01-17 D 111 final 2013-01-12 and now a want a new data.frame which includes

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 and possibly other configurations in the future. Regarding your buildbots, gcc12 is easy to replace by LNT, because the

...This is because of disagreement between ABIs over whether "char" is signed. ARM says no, x86 says yes. > MultiSource/Benchmarks/MiBench/automotive-bitcount/automotive-bitcount.execution_time This is also failing on x86, I think (http://lab.llvm.org:8011/builders/clang-x86_64-debian-fnt/builds/14868/steps/make.test-suite/logs/fail.LLC) > MultiSource/Benchmarks/MiBench/telecomm-FFT/telecomm-fft.execution_time > MultiSource/Benchmarks/Ptrdist/anagram/anagram.execution_time (8 of > SingleSource/Benchmarks/BenchmarkGame/puzzle.execution_time I've also seen failures on t...

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:

...4cZCdmG7gAjhcwCPR+pEbvj nFz0dle5D/aE+ihSlDtl8Nqcgzxw/eXKVzAw95oHmkgyCyPJ9KxIBkPw49pA7zhm S87X8eKr3wLbcqAV9GW2sYwJ1Fz4RQt1Gds0XZ/ELUXLxUuLSBZ7D7NycM6F8VyB WkMoVXcZCBhUcGg830m5JZm+B8dMHLhBC4WwZwXmUTIRSJu+7xEccl82FQgernYQ +EyK0I0cXPBMckExfkg432pQD3SIvhZqEpfsHchaztlAF9+WOhAKdqGeQm1iWdQB p8EqdBGP5iN1g/L+fNt/v/j2EgM6ApxkLMzcMxS6p2FV5F9nHuK+WZj8GzYTYOgz tRiFiZ87cw0OQVzL+d6ba23rEP4f2FyAidvJ6/Mw+MNO1gNOTCuloGIa0NCg3xIh HP26euBhVxJjgM0PApMa =Khje -----END PGP SIGNATURE----- Thank you for your contribution to Debian.