similar to: [LLVMdev] make check-all glitch cmake vs. configure on FreeBSD 8.2

Hello. I've built and `make chech-all` rc3 tarballs using CMake build on FreeBSD 8-STABLE system. Here are results: Failing Tests (10): Clang :: Index/crash-recovery-code-complete.c Clang :: Index/crash-recovery-reparse.c Clang :: Index/crash-recovery.c LLVM :: BugPoint/crash-narrowfunctiontest.ll LLVM :: BugPoint/metadata.ll LLVM :: BugPoint/remove_arguments_test.ll

Hi Daniel, > Sebastian, this looks like it is most likely some kind of fallout from > your changes. Thanks for letting me know about these failing testcases. In the logs of the buildbot: http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273/steps/run.build.step.configure_llvm_1/logs/stdio I see that the bot is configuring llvm with:

Hi, all It seems that rev. 131463 [1] makes LLVM failed to recognize ARM correctly. My best guess is the variable LLVM_HOSTTRIPLE got something like "armv7l-unknown-linux-gnueabi" when LLVM compiled natively on ARM. Then the Arch (armv7l) is not recognized by LLVM. As you can see from attach (llvm-131463-gcc-4.4.1-native-arm2.log), there are a lot failure while running test cases

On Fri, Nov 4, 2011 at 3:11 PM, <spop at codeaurora.org> wrote: > Hi Daniel, > >> Sebastian, this looks like it is most likely some kind of fallout from >> your changes. > > Thanks for letting me know about these failing testcases. > > In the logs of the buildbot: >

I actually tend to agree with spop, it's cleaner to compute things at runtime than at compile time. One particular reason is wanting to pick the best target CPU for the current arch (which may not be what was compiled for). The current JIT target selection logic is really gross, I do believe that it tried to do this, but it probably needs some spring cleaning. Sebastian, can you try and take

On Sun, Jul 3, 2011 at 11:32 PM, Karel Gardas <karel.gardas at centrum.cz> wrote: > Hello, > > I asked here for kind of reference GCC version which LLVM development > team is using for *native* testing on ARM hardware. (no cross > compilation!) last week or so. I've been curious myself how the > situation looks and so I tested LLVM 2.9 as a reference point and LLVM >

Hi, I have successfully built a shared version of LLVM (both 3.0rc4 and 2.9) on Windows 7 using MinGW. From there, I thought I would run the tests located under unittests (i.e. ADTTests, AnalysisTests, ExecutionEnginetests, JITTests, SupportTests, UtilsTests and VMCoreTests). All of them pass without any problem, except for JITTests which fails on the MultiJitTest.JitPool test:

2011/11/18 Alan Garny <alan.garny at dpag.ox.ac.uk>: > I have successfully built a shared version of LLVM (both 3.0rc4 and 2.9) on > Windows 7 using MinGW. From there, I thought I would run the tests located > under unittests (i.e. ADTTests, AnalysisTests, ExecutionEnginetests, > JITTests, SupportTests, UtilsTests and VMCoreTests). All of them pass > without any problem,

Hello, I asked here for kind of reference GCC version which LLVM development team is using for *native* testing on ARM hardware. (no cross compilation!) last week or so. I've been curious myself how the situation looks and so I tested LLVM 2.9 as a reference point and LLVM HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5,

Erik de Castro Lopo <mle+cl <at> mega-nerd.com> writes: > > Hi all, > > I'm compiling current SVN HEAD on Linux/x86. The tests are failing > on PowerPC due to the following assertion failure : > > JITTests: PPCCodeEmitter.cpp:152: unsigned int<unnamed>::PPCCodeEmitter:: > getMachineOpValue(const llvm::MachineInstr&, const

Hi all, I'm compiling current SVN HEAD on Linux/x86. The tests are failing on PowerPC due to the following assertion failure : JITTests: PPCCodeEmitter.cpp:152: unsigned int<unnamed>::PPCCodeEmitter:: getMachineOpValue(const llvm::MachineInstr&, const llvm::MachineOperand&) const: Assertion `MovePCtoLROffset && "MovePCtoLR not seen yet?"'

Hi all, As of r141677 I have a failing regression test, see below. This is for LLVM built with clang on a Intel Atom running FreeBSD8.2. Should I file a bug for this? Thanks, Ed. ******************** TEST 'LLVM :: CodeGen/X86/bswap.ll' FAILED ******************** Script: -- /usr/home/emeewis/build/llvm-debug-clang-configure/Debug+Asserts/bin/llc <

On Mar 20, 2013, at 12:14 PM, Stephen Checkoway <s at pahtak.org> wrote: > I assume the CMAKE_SHARED_LIBRARY_LINK_C_FLAGS and CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS could be set empty initially and then for those that need it, set it (or something else) to -rdynamic. Attached is a small patch that sets CMAKE_SHARED_LIBRARY_LINK_CXXFLAGS to "" (as per your patch which I

On 03/01/2013 02:57 PM, Hal Finkel wrote: Hi Hal, thanks for feedback. > Jiong, I am happy to see the Tile backend being offered for upstream inclusion. Among other things, in the long run, this may help inform and motivate many-core capabilities in LLVM. > > First, can you elaborate on the future maintenance and development plans for the target code? Do you plan to add SIMD support?

----- Original Message ----- > From: "Jiong Wang" <jiwang at tilera.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, cfe-dev at cs.uiuc.edu > Sent: Friday, March 1, 2013 1:34:15 AM > Subject: Re: [LLVMdev] RFC: TileGX, a new backend for Tilera's many core processor >

I'm not working on it, but I might be able to help find the problem. What this means is that you're generating code in PIC mode, and an object that requires a PIC register to reference is being addressed, and no PIC register was allocated. The allocation was supposed to happen in PPCDAGtoDAGISel::Select when the reference was processed, and a MovePCtoLR instruction inserted at that

On Mar 19, 2013, at 12:03 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> What version of cmake are you using? I am getting the opposite >> behavior: every binary is linked using -rdynamic :-( > > BTW, I reported llvm.org/pr15543 to track this. When I first sent the email (in August of last year), I was using cmake 2.8.8. I now appear to be using 2.8.9

On Tue, Dec 8, 2009 at 1:05 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > Nick Lewycky wrote: >> Can you prepare a standalone testcase that demonstrates the problem? See >> unittests/ExecutionEngine/JIT/*.cpp to get your started. > > Probably. I'd essentially have to replicate some minimal runtime > environment and IR as created by the Pure interpreter.

Jeffrey Yasskin wrote: > Not really. I need to find the IR it's compiling into bad code, and > `make check` doesn't give me the command lines so I can gdb them. It's > also going to be tricky for me, who's not familiar with your > implementation, to find which function is crashing and where it's > compiled. Either a patch to JITTest.cpp or an IR file+an lli

Please add a test to http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/JIT/JITTest.cpp?view=markup verifying that recompileAndRelinkFunction() keeps working. Then this fix will look fine to me. On Tue, Dec 22, 2009 at 12:23 AM, Gianluca Guida <glguida at gmail.com> wrote: > On Tue, Dec 22, 2009 at 6:14 AM, Chris Lattner <clattner at apple.com> wrote: >>