search for: mcjittest

...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/DummyR...

...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 tried removing it from the >supported arch list but didn't see any effect. Since MCJIT w...

...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 chang...

...eloc-remote.ll Unit-tests pass. Both A9 bots are running the same Ubuntu (13.03), with the same GCC (4.7.2), and are the same hardware (Panda ES RevB), so it really strikes me as odd that we have such a different behaviour between them. ARM920, compiled with GCC: All tests pass. Unit-test fail: MCJITTest.return_global If I take out the XFAIL on those tests, some bots will fail, others will pass. This is not the solution. It either pass on all, or none. All errors started with David's patch, so I'm assuming it was something enabled by that. It could be a dormant, unrelated bug to his patch,...

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 tes...

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

...make[2]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/unittests/LineEditor' llvm[2]: Compiling LineEditor.cpp for Release+Asserts build llvm[2]: Compiling ImmutableMapTest.cpp for Release+Asserts build llvm[2]: Compiling DebugInfoTest.cpp for Release+Asserts build llvm[3]: Compiling MCJITTest.cpp for Release+Asserts build llvm[2]: Linking Release+Asserts unit test LineEditor (without symbols) llvm[2]: ======= Finished Linking Release+Asserts Unit test LineEditor (without symbols) make[2]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/unittests/LineEditor' llvm[2]: Compiling...

....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/...