similar to: [LLVMdev] LLVM 3.0rc4 / 2.9: failing MultiJitTest.JitPool on Windows 7

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,

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

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:

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

Hi Jeffrey, Thanks for pointing me in the right direction ! I'm not using the JIT in lazy mode, but it was fun to understand the lazy-stub code. Attached you will find a patch which follow your 1st option : a map Stub_address -> JITResolver instance, except that the used map is a "std::map" to apply the same upper_bound trick as in the map CallSiteToFunctionMap of the

Thanks for the patch! I'll clean this up, convert your sample to a unit test, and commit it for 2.7. On Sun, Feb 7, 2010 at 6:09 AM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > Hi Jeffrey, > > Thanks for pointing me in the right direction ! > I'm not using the JIT in lazy mode, but it was fun to understand the > lazy-stub code. > > Attached you will

Thanks Jeffrey ! If possible, keep me inform (on revision number), I'm interested to see how you will do the unit test. (For my future patch... :) ). Thanks again. Olivier. On Wed, Feb 10, 2010 at 6:22 PM, Jeffrey Yasskin <jyasskin at google.com>wrote: > Thanks for the patch! I'll clean this up, convert your sample to a > unit test, and commit it for 2.7. > > On Sun,

Hello everyone, Are there any reasons the unittests in LLVM repo are split into independent executables, e.g. ADTTests, AnalysisTests, etc. Are there any performance or easy-to-use reasons for this? I plan to migrate to GTest from a project where we have all unittests in a single executable. - Paweł -------------- next part -------------- An HTML attachment was scrubbed... URL:

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 >

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,

In eager compilation mode, I don't know of anything that would go wrong with having multiple JITs in the process. However, in lazy compilation mode, we need to map stub addresses to the JIT that knows how to compile them. Right now, that's done by looking up the static "TheJITResolver" variable and assuming it's the only JIT, but we could 1) use a static

Hi everyone ! If I call ExecutionEngine::createJIT (or EngineBuilder::create) more than one time, the second time fails on a assertion "Multiple JIT resolvers?". It seems that the JIT is designed to be a singleton in the process, and I was wondering if it was something mandatory. How hard will it be to make it a non-singleton object ? Is this a JIT-only problem (work needed on JIT

Howdy Folks, I'm working on implimenting centralized authentication for a mixed environment: - Samba(3.0rc4) -> Win2k/XP OpenLDAP User Store -> - nss_ldap -> linux/unix - FreeRadius -> Cisco/HP Networking Equip (My apologies if that doesn't look right for anyone) I have a functional ldap database (openldap-2.0.27-8), and I'd very much like to use Samba 3.x (been

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

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

Summary: ---------------------- Hello, when using the MS NT SrvTools (User & Server Manager for Domains), I get an error when I try to access an individual user's properties ("The following error occurred while accessing the properties of the user <blah> \n The specified procedure could not be found \n The user properties cannot be edited or viewed at this time"); however,

LLVMers, Today starts the fourth and final round of testing for LLVM 3.0. Please visit: http://llvm.org/pre-releases/3.0/rc4/ for the sources. Binaries will follow over the next week as the release team has time to build them. Please build this release candidate, test it out on your projects, and let us know if you find any regressions from the 2.9 release. This is our final release candidate

On 11/17/2011 09:23 AM, Tanya Lattner wrote: > Today starts the fourth and final round of testing for LLVM 3.0. Please > visit: > > http://llvm.org/pre-releases/3.0/rc4/ Works fine for me, running the Pure testsuite, as did all the previous candidates. Are the dragonegg sources for rc4 unchanged? They were included in the previous candidates, but not in rc4. Albert -- Dr. Albert

Hello Bill, Could you please upload the rc4 binaries? Thanks in advance, Ákos