search for: mcjittests

...territory but my guess is that's unlikely. -David ******************** Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. Testing Time: 5.12s ******************** Failing Tests (11): LLVM-Unit :: ExecutionEngine/MCJIT/./MCJITTests/MCJITTest.lazy_function_creator_lambda LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.DefineMaterializingSymbol LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.FallbackDefinitionGeneratorTest LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/DummyRP...

...that's unlikely. > > -David > > ******************** > Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. > Testing Time: 5.12s > ******************** > Failing Tests (11): > LLVM-Unit :: > ExecutionEngine/MCJIT/./MCJITTests/MCJITTest.lazy_function_creator_ > lambda > LLVM-Unit :: > ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.DefineMaterializingSymbol > LLVM-Unit :: > ExecutionEngine/Orc/./OrcJITTests/CoreAPIsStandardTest.FallbackDefinitionGeneratorTest > LLVM-Unit :...

On 2013-03-12 1:28 AM, "Jyotsna Verma" <jverma at codeaurora.org> wrote: >Thanks Dan! > >The ArchSupportMCJIT() functions in >unittests/ExecutionEngine/MCJIT/MCJITTestBase.h uses "Host Triple" to >check >for compatibility. Since we cross-compile on X86, "Host Triple" for us >will >be "X86" which is a supported architecture. I

...that's used by the unit tests doesn't >support remote execution. However, the RemoteMemoryManager has been >improving lately; it could foreseeably be used to add remote execution >support to the tests. That explains why MCJIT test executable (build/unittests/ExecutionEngine/MCJIT/MCJITTests) was an X86 binary in my case. It appears to me that these tests will always fail for cross-compilation unless modified for remote execution. I noticed "TARGET_HAS_JIT" flag in Makefile.config. Can I use this flag to exclude MCJIT and JIT tests when not set? This will be a simpler change...

So, it seems David beat me to it, and the assert has already been removed, but the failures are still inconsistent. A9-check-all, compiled with GCC: Tests XPASS: LLVM :: ExecutionEngine__MCJIT__test-common-symbols-remote.ll LLVM :: ExecutionEngine__MCJIT__test-global-init-nonzero-remote.ll LLVM :: ExecutionEngine__MCJIT__test-ptr-reloc-remote.ll Unit-tests pass. A9-self-host, compiled with

On 18 May 2013 09:56, Tim Northover <t.p.northover at gmail.com> wrote: > According to Amara that assertion was a bit of paranoia so we'd know > if someone tried emitting .rel relocations and sending the result > through MCJIT. However, now we routinely re-relocate using explicit > addends so as he says it can probably just be removed. > Hi Tim, Sorry, I saw that thread

Thanks Dan! The ArchSupportMCJIT() functions in unittests/ExecutionEngine/MCJIT/MCJITTestBase.h uses "Host Triple" to check for compatibility. Since we cross-compile on X86, "Host Triple" for us will be "X86" which is a supported architecture. I tried removing it from the supported arch list but didn't see any effect. I was just wondering if these tests are

Hi Andy/Albert, Sorry for the slow reply, my day job caught up with me. Two bits of progress. (a) MCJIT is working nicely for non-trivial examples in Extempore on x86 and ARM, and (b) the page permissions are now RO again. For your amusement a *very* cheesy video of Extempore running on-the-fly with MCJIT on an ARM Pandaboard. Viewer discretion is advised! https://vimeo.com/60407237 Here is the

Hey Andy, Yep I've tested some non-trivial examples with loads of dependencies, both code and data, global, local and external symbol resolution etc.. Actually this was truly a piece of cake, nothing to do, the memory manager is working really nicely so far as I can tell. Relocations to sections are all working as expected (aside from previously mentioned ARM issue which is probably just

llvm[4]: Compiling PoolAllocate.cpp for Release+Asserts build /home/NIKHILREDDY/WORK/LLVM_SRC/projects/poolalloc/lib/PoolAllocate/PoolAllocate.cpp: In member function ‘virtual bool llvm::PoolAllocate::runOnModule(llvm::Module&)’: /home/NIKHILREDDY/WORK/LLVM_SRC/projects/poolalloc/lib/PoolAllocate/PoolAllocate.cpp:403:16: error: ‘class llvm::Constant’ has no member named

....dir 4.0K build/unittests/LineEditor/CMakeFiles/LineEditorTests.dir 4.0K build/unittests/IR/CMakeFiles/IRTests.dir 4.0K build/unittests/FuzzMutate/CMakeFiles/FuzzMutateTests.dir 4.0K build/unittests/ExecutionEngine/Orc/CMakeFiles/OrcJITTests.dir 4.0K build/unittests/ExecutionEngine/MCJIT/CMakeFiles/MCJITTests.dir 4.0K build/unittests/ExecutionEngine/JITLink/CMakeFiles/JITLinkTests.dir 4.0K build/unittests/ExecutionEngine/CMakeFiles/ExecutionEngineTests.dir 4.0K build/unittests/Demangle/CMakeFiles/DemangleTests.dir 4.0K build/unittests/DebugInfo/PDB/CMakeFiles/DebugInfoPDBTests.dir 4.0K build/unittests/D...