similar to: [LLVMdev] Optimized Nightly Test Regressions

Is it ok sending this results for FreeBSD5.1 at daily/weekly based to this mail list? Now results. Big improvement in llvm tests results from last test result sended. New regressions: Regression.Assembler.ConstantExprFold : FAIL , expected PASS Regression.CodeGen.Generic.2004-04-09-SameValueCoalescing: FAIL , expected PASS Regression.Transforms.PRE.basictest : FAIL

Thanks Vladimir. That's great! Glad you got it working. BTW, the failures you're seeing have been experienced by Chris and I as well. Chris is diligently working on making the LLVM processing more consistent so he track down the problem. A week ago or so, these tests passed at 100%. Reid. On Sun, 2004-06-20 at 15:50, Vladimir Merzliakov wrote: > In attached file. > > Vladimir

In attached file. Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: test2004_06_20.log Type: application/octet-stream Size: 88488 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040620/98042f01/attachment.obj>

On Mon, 21 Jun 2004, Vladimir Merzliakov wrote: > Is it ok sending this results for FreeBSD5.1 at daily/weekly based to this > mail list? A better list for it would be the llvmbugs list for now. I beginning to think that we need a new test results mailing list. We have 3 instances of the nightly tester going now (x86/linux, sparc, ppc) and may have more in the future. The nightly tester

On May 24, 2008, at 12:12 PM, Bill Wendling wrote: > Let us know if you would like extra eyes on the two PPC failures. Many > of us have a lot of experience with C++. :-) Do you know where these > allocations are? I don't mind if people help out, so here's some information: FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/ 2006-11-04-ReplacingZeros.ll Failed with

On May 24, 2008, at 4:25 PM, Marcel Moolenaar wrote: > On May 24, 2008, at 12:12 PM, Bill Wendling wrote: >> Let us know if you would like extra eyes on the two PPC failures. >> Many >> of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: Nice!

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

Hello everyone, I'm wrestling with the LLVM unit and regression tests now and would like to discuss some changes to make. I will be preparing patches, but any input/ideas are welcome. I leave "where the tests should run" question out for the scope yet. Let's review what kind of tests we have and how to handle them correctly. We have 3 types of unit and regression tests: 1.)

Hi, I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and have the following test results to share. Summary below, full log at: http://www.csl.cornell.edu/~fang/sw/llvm/r146586-powerpc-darwin8-results.txt The only edits required were those I posted to llvm-commits yesterday (re: "some missing clang libs"). And I also edited LitConfig.py to point to

Hi to all LLVMers first of all many thanks for new great LLVM release! now to the question. i was quite happy to look from time to time through regularly built benchmarking html-tables. now i cant easily find it anymore. In contrast to people, who just recently stuck to LLVM, I do know that these benchmarking tests did exist. they don't. i hope audience of ppl like me will be not forgotten

hello everybody, i just commited a pkgsrc for dovecot nightly cvs-snapshots to the pkgsrc-wip repository for NetBSD - this will hopefully go into base pkgsrc, soon. please see http://pkgsrc-wip.sourceforge.net/ on how to obtain pkgsrc-wip. ----- Forwarded message from Tom Hensel <tomhensel at users.sourceforge.net> ----- Date: Sun, 22 Feb 2004 11:18:52 -0800 From: Tom Hensel

Author: maybee Repository: /hg/zfs-crypto/gate Revision: 919f120139aa174a9eb20e7fdb9026ab851357d6 Log message: 6398177 zfs: poor nightly build performance in 32-bit mode (high disk activity) 6420920 File truncate produces incorrect log record Files: update: usr/src/uts/common/fs/zfs/arc.c update: usr/src/uts/common/fs/zfs/zfs_znode.c

I've noticed something strange with a 3.4 test box that is basically just sitting here in the lab. I've got it configured to forward me the Logwatch run (which seems to go off at 4:02am by default). Every couple of days, that logwatch run goes missing. I haven't really dug down to find out if the cron job is crapping out or if postfix is dropping the report on the floor. Is

Hello, On some occasions with 3.4 for example I seemed to hit bugs that not only were already reported, but in some cases even fixed (like some recent quota failed issue). Is there a place where I could get nightly or at least weekly RPMs? This way at least I'll hit new or unresolved bugs ... :-) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro

Hello Folks, In pour present Samba-3 setup we update user passwords in our LDAP backend. We only have access to the encrypted NTLM passwords and use Perl scripts to do this. Beyond importing the user database with the 'Classic upgrade' method, will we be able to adapt our Perl scripts so that we can keep updating the internal Samba-4 database with the encrypted passwords as we did with

When compiling a 2.6.10-xen0 kernel I get the following error: CC drivers/xen/balloon/balloon.o drivers/xen/balloon/balloon.c: In function `balloon_process'': drivers/xen/balloon/balloon.c:209: error: `phys_to_machine_mapping'' undeclared (first use in this function) drivers/xen/balloon/balloon.c:209: error: (Each undeclared identifier is reported only once

Today''s nightly testing for Xen:#17152 is blocked by following issue: Bug#1181, HVM can not be created with qcow image, http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1181 It should be c/s 17133 that introduced this issue. And here is another update for our testing, the gcc version of our build system has been upgraded to v4.1.1; from now on, our testing result is based on gcc

Hello, I have set up a build machine for Xen. Currently it builds the version checked out from Subversion with the latest testing version from Xen repository for Sarge every night. deb http://naquadah.org/~jd/debian/xen stable main I plan to upload real and official backports to backports.org as soon as we will upload a version to sid. Any comment welcome, Cheers, -- Julien Danjou

This is just a note to point out that LLVM now has a automated nightly regression test suite. The results of which are here: http://llvm.cs.uiuc.edu/testresults/ The script is checked into CVS in the utils/NightlyTest* files. This is meant to keep track of the progress LLVM makes with bug fixes, and help ensure that LLVM get more solid as it is developed, not more fragile. Currently we only