search for: obsequious

Nathan Bullock wrote: > Just kidding. :-) My gosh. Your subject line nearly gave me a heart attack! :) > > Hi, I was just doing a Google search on my name and I > ran across a site that actually had a reference to > Obsequi a program I wrote almost three years ago now. > I thought the program had been forgotten a long time > ago (forgotten might not be the right word,

Just kidding. :-) Hi, I was just doing a Google search on my name and I ran across a site that actually had a reference to Obsequi a program I wrote almost three years ago now. I thought the program had been forgotten a long time ago (forgotten might not be the right word, I'm not sure if it was ever remembered). Anyway I was just wondering how John Criswell ever ran across such a low

After going through 17000+ lines of output, I come up with the following... =========================================== In file included from /usr/home/llvm/obj/projects/llvm-test/../../../projects/llvm-test/MultiSource/Applications/hexxagon/hexxagonmove.cpp:26: /usr/include/sys/timeb.h:43: error: `time_t' does not name a type

Ignore the missing malloc.h errors. I screwed up badly. I was undoing my alloca.h hack and removed the wrong file. On Tue, 16 Nov 2004 23:29:43 -0800 Jeff Cohen <jeffc at jolt-lang.org> wrote: > After going through 17000+ lines of output, I come up with the following... > > =========================================== > > In file included from

I updated my source tree and after putting malloc.h back things look a lot better. Still getting a large number of JIT-only failures. There is now only one assertion failure: /home/cfe/x86/llvm-gcc/bin/g++ -I/usr/home/llvm/obj/projects/llvm-test/MultiSource/Benchmarks/Prolangs-C++/city -I/usr/home/llvm/obj/projects/llvm-test/../../../projects/llvm-test/MultiSource/Benchmarks/Prolangs-C++/city

Hi all, I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981).  Results can be viewed on: http://188.40.87.11:8000. There are mainly five new tests and each test is run with 10 samples: clang (run id = 27):  clang -O3 pollyBasic (run id = 28):  clang -O3 -load LLVMPolly.so pollyNoGen (run id = 29):  pollycc -O3 -mllvm -polly-optimizer=none

On Wed, 17 Nov 2004, Jeff Cohen wrote: > I updated my source tree and after putting malloc.h back things look a lot better. Still getting a large number of JIT-only failures. There is now only one assertion failure: > > /home/cfe/x86/llvm-gcc/bin/g++ -I/usr/home/llvm/obj/projects/llvm-test/MultiSource/Benchmarks/Prolangs-C++/city

Hi, I get the following failures when I run the test-suite on linux (Ubuntu 12.04) using LNT (lnt runtest nt ...): (all are execution failures) MultiSource/Applications/Burg MultiSource/Applications/ClamAV MultiSource/Applications/lemon MultiSource/Applications/obsequi MultiSource/Benchmarks/MiBench/automotive-bitcount

On 03/17/2010 10:12 PM, Tanya Lattner wrote: > The 2.7 binaries are available for testing: > http://llvm.org/pre-releases/2.7/pre-release1/ > > You will also find the source tarballs there as well. > > We rely on the community to help make our releases great, so please help > test 2.7 if you can. Please follow these instructions to test 2.7: > > /To test llvm-gcc:/

On Mar 24, 2010, at 2:47 PM, Török Edwin wrote: > On 03/17/2010 10:12 PM, Tanya Lattner wrote: >> The 2.7 binaries are available for testing: >> http://llvm.org/pre-releases/2.7/pre-release1/ >> >> You will also find the source tarballs there as well. >> >> We rely on the community to help make our releases great, so please help >> test 2.7 if you

On 08/10/2013 06:59 PM, Star Tan wrote: > Hi all, > > I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981). Results can be viewed on: http://188.40.87.11:8000. Hi Star Tan, thanks for the update. > There are mainly five new tests and each test is run with 10 samples: > clang (run id = 27): clang -O3 > pollyBasic (run id =

Hi Tanya, I've been checking the state of the various llvm-test failures on X86/Linux with GCC 3.4.6 and llvm-gcc4. I haven't finished this, but I thought the following might be useful for other people that are testing the release on Linux. Each group of failing tests below is followed by a comment about why its failing. llc /MultiSource/Applications/oggenc/oggenc jit

At 2013-08-12 01:18:30,"Tobias Grosser" <tobias at grosser.es> wrote: >On 08/10/2013 06:59 PM, Star Tan wrote: >> Hi all, >> >> I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981).  Results can be viewed on: http://188.40.87.11:8000. > >Hi Star Tan, > >thanks for the update. >

Hi, I figured out how to resolve the failures. I noticed that Mountain Lion includes Bison 2.3 while Ubuntu 12.04 includes Bison 2.5. I installed Bison 2.3 from source in Ubuntu and the failures went away. I'm a little concerned that the bison version fixed all the failures I was seeing. To my knowledge the only failing test that depended on bison was Burg. It almost looks like one failure

The 2.7 binaries are available for testing: http://llvm.org/pre-releases/2.7/pre-release1/ You will also find the source tarballs there as well. We rely on the community to help make our releases great, so please help test 2.7 if you can. Please follow these instructions to test 2.7: To test llvm-gcc: 1) Compile llvm from source and untar the llvm-test in the projects directory (name it

Hi Tanya, Here's my second attempt on Fedora Core 5. The changes this time are: 1. Using GCC 4.0.3 as the compiler 2. Building everything from source (no pre-built binaries used) BUILD LLVM WITH GCC 4.0.3 * No issues, just the usual warnings. BUILD LLVM-GCC WITH GCC 4.0.3 * No issues RUN LLVM-TEST WITH GCC 4.0.3 * The following failures were encountered. Some of them are

I created the 1.9 release branch last night. As a reminder, please do not check in any code changes to the release branch. Please send me email if you have changes that need to be merged into the release branch. To check out the release branch: cvs -d <CVS Repository> co -r release_19 llvm cvs -d <CVS Repository> co -r release_19 llvm-test cvs -d <CVS Repository> co -r

There is almost certainly a bug in lnt or the makefiles. I changed the body of Burg main to the following: + printf("Hello World\n"); + return 0; I re-ran the test-suite again and got the following errors: --- Tested: 986 tests -- FAIL: MultiSource/Applications/Burg/burg.execution_time (494 of 986) FAIL: MultiSource/Applications/ClamAV/clamscan.execution_time (495 of 986) FAIL:

On 03/30/2010 09:15 PM, Tanya Lattner wrote: > > Thanks for testing the release! > >> Tests were run on x86-64, Debian unstable, Linux 2.6.33, gcc 4.4.3, >> 64-bit. I built srcdir == objdir, I have built llvm and clang myself, >> and used the binaries for llvm-gcc. >> >> 1. llvm-gcc 2.7 vs 2.6 >> compared to my results from Aug 31 2009, ignoring CBE

This is very interesting work. Thanks. Quick questions / comments. 1. What's the algorithm complexity? 2. Please rename -vectorize to -bb-vectorize since this is a specific kind of vectorization. 3. Have you tried non-x86 targets? Does it work? If not, what would it take to make it work? I am concerned that LLVM currently does not have a cost model for vectorization. That's necessary for