similar to: [LLVMdev] libcalls test fails to run

On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: > 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any ideas about what is going wrong here? No idea why this stuff was there... Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92512) +++

On Tue, Jan 05, 2010 at 10:05:21AM -0800, Chris Lattner wrote: > looks like some lines got moved, fixed on mainline, thanks. Not really fixed :-) Please commit this: Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92749) +++ TEST.libcalls.Makefile (working copy) @@ -23,10 +23,10 @@

On Jan 5, 2010, at 6:22 AM, Gregory Petrosyan wrote: > On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: >> 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any >> ideas about what is going wrong here? > > No idea why this stuff was there... looks like some lines got moved, fixed on mainline, thanks. -Chris >

Doh, thanks, done. -Chris On Jan 5, 2010, at 11:27 AM, Gregory Petrosyan wrote: > On Tue, Jan 05, 2010 at 10:05:21AM -0800, Chris Lattner wrote: >> looks like some lines got moved, fixed on mainline, thanks. > > Not really fixed :-) Please commit this: > > Index: TEST.libcalls.Makefile > =================================================================== > ---

On Tue, Jan 05, 2010 at 11:42:10AM -0800, Chris Lattner wrote: > Doh, thanks, done. LOL. Next patch should be titled 'really really really fix this' :-) Please apply the last part of the diff, too: Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92757) +++ TEST.libcalls.Makefile (working copy) @@

> LLVM tools and LLVM-GCC I've built seem to work. > Can it be due to LLVM_SRC_ROOT == LLVM_OBJ_ROOT? No. This is usually due to absence of llvm-gcc. You need reconfigure llvm once again with lvm-gcc path added and make sure it was hooked properly (look into Makefile.config for paths, etc). -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg

On Sun, Dec 13, 2009 at 11:34 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> LLVM tools and LLVM-GCC I've built seem to work. >> Can it be due to LLVM_SRC_ROOT == LLVM_OBJ_ROOT? > No. This is usually due to absence of llvm-gcc. You need reconfigure > llvm once again with lvm-gcc path added and make sure it was hooked > properly (look into

After following all steps from http://llvm.org/docs/TestingGuide.html#testsuiterun, I've got this: make[1]: Entering directory `/cygdrive/c/projects/thesis/llvm-suite-2.6/llvm-2.6/projects/test-suite/SingleSource' make[2]: Entering directory `/cygdrive/c/projects/thesis/llvm-suite-2.6/llvm-2.6/projects/test-suite/SingleSource/UnitTests' make[3]: Entering directory

Reid Spencer wrote: > Have you modified the makefile in any way? Note that sse.expantfft.bc should be sse.expandfft.bc no, did'nt change it. the typo before seems to be an error while copying from the terminal. i've cleaned everything and tried again. this is the messsage: [brandner:/localtmp/brandner/dev/llvm-test:529] make -j1 TEST=nightly 2>&1 | tee report.nightly.raw.out

In order to test the tail call optimization i created quite a few .ll files and added them to the SingleSource directory in the test-suite. For example llvm-test/SingleSource/Tailcall/tailcall1-2.ll. Since i don't want opt to inline the tailcalls away :) i changed the rules in the Makefile situated in the TailCall directory. I want to compare the output of a file compile with normal llc with

Hi, I am currently trying to set up new performance and regression testers for Polly and LLVM and would like to XFAIL two test cases. I am using the LNTBuilder instead of the NightlyTestBuilder out of the assumption that the LNTBuilder is the more modern solution. However, when trying to xfail test cases I realized the xfail=[] parameter of getLNTFactor is ignored. Previously this was not an

On Sun, Dec 13, 2009 at 8:17 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> It looks to me that this: >> >> make[4]: *** No rule to make target `Output/sse.expandfft.linked.rbc', >> needed by `Output/sse.expandfft.linked.bc'.  Stop. > Well, I have no idea then. makefiles of testsuite are well-known for > such erratic behavior :( For the

On Saturday 15 September 2007, Tanya Lattner wrote: > 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). I tried to do this, but ran into trouble. LLVM itself compiled fine. GCC compilation is broken when Java support is enabled. I can file a detailed bug report

Reid, I think it is the first time it is run that the errors occcur !? Not sure but that would seem logical. Aaron

hello, i've problems running the llvm-test suite using debian linux and make 3.81. it works fine on my laptop, running openSuse and make 3.81. i already tried to install make 3.75 and 3.79, both did not work. the error message is: make[1]: *** No rule to make target `Output/sse.expantfft.bc', needed by `Output/sse.expandfft.linked.rbc'. Stop. using make -p, i see that

>> Yes, well, i64 is a legal type, that's how it is. However, i64s are >> always stored in two 32-bit registers and in some cases need complicated >> instruction patterns for easy things (such as add, sub and so on) that >> basically simulate the i64 behaviour with a sequence of i32 >> instructions. > I think you're misunderstanding what it means for a type

On Sun, Jan 8, 2012 at 2:37 AM, Johannes Birgmeier <e0902998 at student.tuwien.ac.at> wrote: >> Is i64 a legal type on your target?  If so, you might need to hack the >> code generator a bit; no in-tree target has a legal integer type that >> doesn't support shifts.  If not, I have no idea how you're getting >> that error. > > Yes, well, i64 is a legal

> Is i64 a legal type on your target? If so, you might need to hack the > code generator a bit; no in-tree target has a legal integer type that > doesn't support shifts. If not, I have no idea how you're getting > that error. Yes, well, i64 is a legal type, that's how it is. However, i64s are always stored in two 32-bit registers and in some cases need complicated

Hello, my target has libcall support for long long shifts. I already have the following lines in my Lowering constructor: setLibcallName(RTLIB::SHL_I64, "__llshl"); setLibcallName(RTLIB::SRL_I64, "__llshru"); setLibcallName(RTLIB::SRA_I64, "__llshr"); and setOperationAction(ISD::SHL, MVT::i64, Expand); setOperationAction(ISD::SRA, MVT::i64,

Hi, I would like to propose that when available, if a C builtin function has an equivalent llvm intrinsic, that the intrinsic be the preferred form. The equivalent clang __builtin should emit the intrinsic, and SimplifyLibCalls should replace calls with the intrinsic. For context, this came up on an old review thread: http://reviews.llvm.org/D5896 There are a few motivations for this: 1.