similar to: [LLVMdev] Nightly Tester LOC Back Online

Hey All, I have been making some changes to the nightly tester that will hopefully make debugging problems and performance issues easier. The big change is nightly test results will now be kept in a central location (http://llvm.org/nightlytest/index.php). I have committed a new file to utils/ called 'NewNightlyTest.pl'. It *should* behave almost exactly like the previous NightlyTest.pl

Reid, Click on any of these logs and you'll see the same asm parsing issues. It's been going on for much of the week. http://llvm.org/nightlytest/machines/2006-12-29_05:40:12-Build-Log.txt http://llvm.org/nightlytest/machines/2006-12-29_05:40:12-Build-Log.txt llvm[4]: Compiling stacker_rt.ll to stacker_rt.bc for Release build (bytecode)

hello everybody, I have added few improvements to my patch. Please review the new patch directly. Thanks! -Rajika On Sun, Jul 6, 2008 at 9:17 PM, Rajika Kumarasiri <rajikacc at gmail.com> wrote: > hello every body. > > Here with I have attached the patch which compile the llvm-gcc using > nightly tester script. This patch add the following capabilities to the >

hello every body. Here with I have attached the patch which compile the llvm-gcc using nightly tester script. This patch add the following capabilities to the NewNightlyTester.pl script. 1. Checkout the llvm-gcc4.2 source from the SVN. 2. Compile the checkout llvm-gcc4.2 source tree. 3. Gather the configure/make out put informations. 4. Add the (3) informations to the %hash_of_data hash to be

Rajika, A couple of comments: - You should provide a way to specify where llvm-gcc is built (just like llvm). - I would highly recommend allowing the user to only update llvm-gcc and not check it out from scratch each time. Checking out llvm-gcc is very time consuming. You would need to make sure that llvm and llvm-gcc have the same rev number and nuke the llvm obj/install dirs so you get a

On Sat, 30 Dec 2006, Reid Spencer wrote: > You all just need remove "stacker_rt.ll". the stacker_rt.ll is a > generated file, not source. The Makefile should have a dependency on > llvm-gcc for it, but doesn't. Just remove stacker_rt.ll and the problem > will go away. This presumably doesn't impact the testers, as they start from a clean build every night. The

On Sat, 2006-12-30 at 11:53 -0800, Chris Lattner wrote: > On Sat, 30 Dec 2006, Reid Spencer wrote: > > You all just need remove "stacker_rt.ll". the stacker_rt.ll is a > > generated file, not source. The Makefile should have a dependency on > > llvm-gcc for it, but doesn't. Just remove stacker_rt.ll and the problem > > will go away. > > This

Hi Jeff, On Tue, 2007-01-02 at 20:17 -0800, Jeff Cohen wrote: > So when will the public mirror be updated? That version of llvm-gcc > still doesn't have the patch. It could be a while. Apparently the machine that ran the nightly job had a disk failure and some of the cron jobs etc are dead. The commits have been made on Apple's internal SVN server but haven't made it to the

Hi Devang, Unfortunately, there's no way to see the build log unless you're on the machine from which the report was generated. If you can log in to Grawp's machine then it should be in the "WEBDIR". It is most likely mis-compiling because the needed llvm-gcc patch has not been applied after the SETCC patch to LLVM was committed last weekend. Reid. On Fri, 2006-12-29 at

On Mon, 2007-01-01 at 00:44 -0800, Evan Cheng wrote: > Ok, so I guess the issue is llvm-gcc has to be updated. There are > some issues with the Apple svn repository so I checked out a copy > from the public mirror. Looks the latest patch hasn't made it through: Yeah, it should have just made it througha couple hours ago, but not at the time of your writing this email. Reid.

Daniel Dunbar wrote: > Did you manage to solve your issue yet, I just had the same problem > and found out that the problem was that I had redefined LLVMGCC > which was (eventually) causing LCC1 to get defined to garbage in Makefile.rules. > Since the .bc target depends on the source and LCC1 this was basically > breaking all the rules. I haven't fixed it yet, but I haven't

Dear All, I need one or more volunteers to try out their nightly testers with the -usesvn option. We're not running on here at the University of Illinois regularly, so if someone could try one of theirs out before tomorrow 9:00 am CDT, I'd be very appreciative. Thanks. -- John T.

hi all, As a part of GSoC 2008 project, I am improving the llvm nightly tester. Now I am in the process of understanding the nightly tester source[1] together with its documentation[2](of course which I am planning to improve). I will ask any thing that need to clarify from the list. Thanks! -Rajika [1] - http://llvm.org/viewvc/llvm-project/nightly-test-server/trunk/ [2] -

So when will the public mirror be updated? That version of llvm-gcc still doesn't have the patch. Reid Spencer wrote: > On Mon, 2007-01-01 at 00:44 -0800, Evan Cheng wrote: > >> Ok, so I guess the issue is llvm-gcc has to be updated. There are >> some issues with the Apple svn repository so I checked out a copy >> from the public mirror. Looks the latest

Hard to tell what's wrong. Perhaps /usr/local/bin is not part of path for a cron job? You should add NewNightlyTest.pl -noremove -release options. That leaves the build directory around for you examine it afterwards. Just manually delete the build directory before running NewNightlyTest.pl. Evan On Jul 20, 2008, at 6:00 PM, Nick Lewycky wrote: > I've noticed that my nightly

On Sat, 30 Dec 2006, Reid Spencer wrote: >>> You all just need remove "stacker_rt.ll". the stacker_rt.ll is a >> rebuilt so they output proper .ll files. Reid, can you change the >> makefile rule to use "llvm-gcc -S -emit-llvm -o - | llvm-upgrade > $@" or >> the equivalent? > > Which makefile rule? The rule in the stacker makefile that

On Mar 9, 2009, at 8:53 AM, Duncan Sands wrote: > This nightly tester is now using an llvm-g++ that produces the new > ODR linkage > types. This means that many more functions are being considered by > the > inter-procedural optimization passes (for example, "linkonce" > functions defined > in a header). The result seems to be pretty huge swings (both good

My main complaints about the nightly tester are: Loading the web pages is waaay tooo sllooooow The information provided is not terribly useful for tracking down bugs. What bug fixers need is environment+command line options adequate to reproduce the problem. Access to the run logs would be a good start. On Apr 4, 2008, at 9:22 PM, Rajika Kumarasiri wrote: > hi all, > After having

Hi Chris, > Can you check to see if the stepanov_container/fftbench regressions > are real? If so, it would be very interesting to know what is "going > wrong" on them. I think these may not be real. This version of llvm-gcc was built with checking enabled - does this turn on checking in libstdc++? It seems that a bunch of linkonce libstdc++ checking code is now being

Ok, so I guess the issue is llvm-gcc has to be updated. There are some issues with the Apple svn repository so I checked out a copy from the public mirror. Looks the latest patch hasn't made it through: c++ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -pedantic -Wno-long- long -Wno-variadic-macros -mdynamic-no-pic -DHAVE_CONFIG_H -Wno- unused