similar to: [LLVMdev] [RC3] FreeBSD status.

Hi, I noticed that the following regression tests fail when building a config generated with CMake. When building with a config generated with configure, all is well. I get the same results when using gcc-4.2.1 and clang-trunk. It seems to me that there's a glitch in de CMake config somewhere. I doing a verbose build right now to investigate, but maybe someone already knows what's

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: >

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:

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?"'

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

Hi all, while writing a testcase thate needed to do a grep containg {, I found that the DejaGNU test framework didn't handle those very well. It's a bit of a fuss to escape accolades properly, but most of all the framework seemed to silently ignore errors in the escaping (and just not run the command then). See [1]. Fixing the framework resulted in 80 of the tests failing. I spent the

Pinging again, more loudly :-) Michael Muller wrote: > > Ping. (looking for someone to review or commit this, thanks) > > Michael Muller wrote: > > > > Thanks, Duncan - > > > > > Hi Michael, > > > > > > > --- lib/ExecutionEngine/JIT/JITEmitter.cpp (revision 163478) > > > > +++ lib/ExecutionEngine/JIT/JITEmitter.cpp

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: >>

On Tue, Dec 22, 2009 at 5:51 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > 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. Here it is. Unfortunately I'm not exactly a C++ guy so I'm open to

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 >