similar to: [LLVMdev] Building Test Suite Still Not Successful

Hello; I was able to build and install llvm(3.0) under Ubuntu 11.10 (using the ./configure script found under llvm source, and then make and make install). While configuring, I gave --prefix as a directory where I would like llvm to be installed. I did not give --with-llvmgccdir and the --enable-optimized argument to configure. Because 3.0 doesn't come with llvmgcc source/binaries and I

Perhaps you noticed that LLVM gained a new optimizing register allocator yesterday (r130568). Linear scan is going away, and RAGreedy is the new default for optimizing builds. Hopefully, you noticed because your binaries were suddenly 2% smaller and 10% faster*. Some noticed because LLVM started crashing or miscompiling their code. Greedy replaces a fairly big chunk of the code generator, so

On Jul 24, 2011, at 3:02 AM, Duncan Sands wrote: > A big compile time regression. Any ideas? > > Ciao, Duncan. False alarm. For some reason that I have not yet been able to figure out, these tests run significantly more slowly when I run them during the daytime, which I did for that run. I checked a few of the worst regressions reported here and they all recovered in subsequent

A big compile time regression. Any ideas? Ciao, Duncan. On 22/07/11 19:13, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/253/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time > Current 253 0 2011-07-22 16:22:04

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

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

Hello, I was interested in how much Type-Based Alias Analysis helps to optimize code. For that purpose, I've compared three sets of benchmarks: compiled without TBAA, compiled with a default TBAA metadata format, and compiled with new TBAA metadata format. As a set of benchmarks, I've used the LLVM test suite (http://llvm.org/docs/TestingGuide.html#test-suite-overview) which has a lot of

On Jul 5, 2012, at 1:33 AM, Duncan Sands wrote: > Hi Bill, > >> Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? > > I don't see any relevant LLVM changes, so I guess clang C++ compilation slowed > down due to some clang changes. I'm not going to investigate this. > Crumbs. John, Do you know of anything that went into

On Mar 24, 2011, at 7:23 AM, José Fonseca wrote: >>> >> I normally use 403.gcc, but if you don't have SPEC sources, these tests in the nightly test suite take a while to compile: >> >> MultiSource/Applications/ClamAV >> MultiSource/Applications/JM/ldecod >> MultiSource/Applications/JM/lencod >> MultiSource/Applications/SPASS >>

On 03/24/2011 03:30 PM, Jakob Stoklund Olesen wrote: > > On Mar 24, 2011, at 7:23 AM, José Fonseca wrote: >>>> >>> I normally use 403.gcc, but if you don't have SPEC sources, these >>> tests in the nightly test suite take a while to compile: >>> >>> MultiSource/Applications/ClamAV >>> MultiSource/Applications/JM/ldecod

On 03/16/2011 03:39 PM, Jakob Stoklund Olesen wrote: > On Mar 16, 2011, at 6:19 AM, José Fonseca wrote: > > >> On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen wrote: >> >>> On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote: >>> >>> >>>> This series of patches address several issues causing memory usage

On Mar 16, 2011, at 6:19 AM, José Fonseca wrote: > On Tue, 2011-03-15 at 20:29 -0700, Jakob Stoklund Olesen wrote: >> On Mar 15, 2011, at 4:15 PM, jfonseca at vmware.com wrote: >> >>> This series of patches address several issues causing memory usage to grow >>> indefinetely on a long lived process. >> >> Thanks for working on this. >>

Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? -bw On Jun 20, 2012, at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > Did something change with exception handling recently? A bunch of lit bots are > showing slower compile times for many tests. > > Ciao, Duncan. > > On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu

Hi Bill, > Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? I don't see any relevant LLVM changes, so I guess clang C++ compilation slowed down due to some clang changes. I'm not going to investigate this. Ciao, Duncan. > > -bw > > On Jun 20, 2012, at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > >> Did

Tanya, Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5) HIGH LEVEL COMMENTS * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't that be llvm-1.9? * LLVM was built in Release mode in all cases * I don't think this is ready for release. In particular the llvm-gcc4 binary seg faults on FC 5 for most of llvm-test programs. *

Did something change with exception handling recently? A bunch of lit bots are showing slower compile times for many tests. Ciao, Duncan. On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu wrote: > > lab-mini-03__O0-g__clang_DEV__x86_64 test results > <http://llvm.org/perf/db_default/v4/nts/1283?compare_to=1278&baseline=999> > > Run Order Start Time Duration >

Target: FreeBSD 6.2-STABLE on i386 autoconf says: configure:2122: checking build system type configure:2140: result: i386-unknown-freebsd6.2 [...] configure:2721: gcc -v >&5 Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 [...] objdir != srcdir, for both llvm and gcc. Release build. llvm-gcc 4.2 from source.

Hi, LLVM 2.1-pre1 test results: Linux (SUSE) on x86 (P4) Release mode, but with assertions enabled LLVM srcdir == objdir # of expected passes 2250 # of expected failures 5 I ran the llvm-test suite on my desktop while I was also working on that PC, so don't put too much trust in the timing info. Especially during the "spiff" test the machine was swapping

On Fri, Sep 14, 2007 at 11:42:18PM -0700, Tanya Lattner wrote: > The 2.1 pre-release (version 1) is available for testing: > http://llvm.org/prereleases/2.1/version1/ > > [...] > > 2) Download llvm-2.1, llvm-test-2.1, and the llvm-gcc4.0 source. > Compile everything. Run "make check" and the full llvm-test suite > (make TEST=nightly report). > > Send

Target: FreeBSD 7.0-RC1 on amd64. autoconf says: configure:2122: checking build system type configure:2140: result: x86_64-unknown-freebsd7.0 [...] configure:2721: gcc -v >&5 Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] [...] objdir != srcdir, for both llvm and gcc. Release