search for: weliveindetail

...t handling >>> of errors passed between function call hierarchies in more complex >>> scenarios. >>> For this I should point to the other example in the code, where it's >>> applied to llvm::object::createBinary(): >>> >>> https://github.com/weliveindetail/ForceAllErrors-in-LLVM/blob/master/test/TestLLVMObject.h#L13 >>> >>> Here it detects and runs 44 different control paths, that can hardly be >>> covered by a unit test altogether, because they don't depend on the input >>> to creatBinary() but rather on the e...

...owever, it can also verify correct handling >> of errors passed between function call hierarchies in more complex >> scenarios. >> For this I should point to the other example in the code, where it's >> applied to llvm::object::createBinary(): >> https://github.com/weliveindetail/ForceAllErrors- >> in-LLVM/blob/master/test/TestLLVMObject.h#L13 >> >> Here it detects and runs 44 different control paths, that can hardly be >> covered by a unit test altogether, because they don't depend on the input >> to creatBinary() but rather on the environ...

...ient test data. In contrast to unit tests, however, it can also verify correct handling of errors passed between function call hierarchies in more complex scenarios. For this I should point to the other example in the code, where it's applied to llvm::object::createBinary(): https://github.com/weliveindetail/ForceAllErrors-in-LLVM/blob/master/test/TestLLVMObject.h#L13 Here it detects and runs 44 different control paths, that can hardly be covered by a unit test altogether, because they don't depend on the input to creatBinary() but rather on the environment the test runs in. Am 27.07.17 um 16:46...

...e to time I found issues in the execution paths of my error cases and got annoyed by their naturally low test coverage. So I started sketching a test that runs all error paths for a given piece of code to detect these issues. I just pushed it to GitHub and added a little readme: https://github.com/weliveindetail/ForceAllErrors-in-LLVM Are there people on the list facing the same issue? How do you test your error paths? Could this be of use for you if it was in a reusable state? Is there something similar already around? Anyone seeing bugs or improvements? Could it maybe even increase coverage in the LLVM...

...035 still persists: CMake Error at /usr/lib/llvm-9/lib/cmake/llvm/LLVMExports.cmake:1323 (message):   The imported target "yaml-bench" references the file      "/usr/lib/llvm-9/bin/yaml-bench"   but this file does not exist. Here's a minimal repro: https://travis-ci.org/weliveindetail/apt-llvm-9-dev-repro/builds/619590445#L204 Is anyone else seeing this too? Is there an obvious fix that I don't see? What's your workarounds? My current workaround is ridiculous, but works for me: https://github.com/weliveindetail/apt-llvm-9-dev-repro/commit/86497a3b#diff-3254677a7917c6c0...

Hi, I have migrated an LLVM front-end from LLVM 3.5 to 3.8 and now to 3.9 and ORC, and there is a concept which I could not transfer. Consider: extern "C" { void somefunc() {} } … auto llvmfunc = llvm::Function::Create(type, llvmFunction::PrivateLinkage, "bla", module)); executionengine.addGlobalMapping(llvmfunc, &somefunc); // now I have llvmfunc to work with and

...4_t)Result <= INT32_MAX) && "Relocation > overflow", file > \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line 81 It's a limitation of the COFF/PE format and unrelated to exceptions. This patch explains it and shows a workaround: https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f > Is there no hope left? Well at least I am not aware of a solution. Am 28.09.17 um 16:04 schrieb bjoern.gaier at horiba.com: > Hello Stefan, > > I'm happy someone replied to my problem! Many thanks! To be honest... > I d...

...32_MAX) && "Relocation overflow", > file \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, > line 81 > > It's a limitation of the COFF/PE format and unrelated to exceptions. This > patch explains it and shows a workaround: > https://github.com/weliveindetail/pj-llvm/commit/ > 97cd336d458ae9c73232d1b539ceefcdb2f5eb0f > > Is there no hope left? > > Well at least I am not aware of a solution. > > Am 28.09.17 um 16:04 schrieb bjoern.gaier at horiba.com: > > Hello Stefan, > > I'm happy someone replied to my problem! Many...

Hi all, I am having hard time figuring out how I should use the API for JIT in LLVM 6. In LLVM 3.9 I am used to adding all objects at once and emitAndFinalizing them all: handle = objectLayer.addObjectSet(objectFiles, memoryManager, resolver); objectLayer.emitAndFinalize(handle); In LLVM 6.0 the objects are added one by one: auto handle = objectLayer.addObject(objectFile, resolver).get();

Hi Geoff, hi Alex If you implement the GDB JIT Interface in your Orc JIT, this is in general possible (at least from the JIT's point of view) with both debuggers, GDB and LLDB. Please have a look at the example here: https://github.com/weliveindetail/JitFromScratch/tree/jit-debug/gdb-interface You will probably need to adjust the code depending on the LLVM version you are using. As described in the readme, however, getting it to work in practice depends on a few more details. To Keep it short: * Linux: works out of the box * macOS: possible, b...

ok i have managed to compile using lli (jit) as follows: but i dont get assembly file? my sum-main.c file is: #include <stdio.h> #include<stdlib.h> int sum(int a, int b) { return a + b; } int main(int argc, char** argv) { printf("sum: %d\n", sum(atoi(argv[1]), atoi(argv[2])) + sum(atoi(argv[1]), atoi(argv[2]))); return 0; } and i used the following steps to compile. clang

...789 Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- https://weliveindetail.github.io/blog/ https://cryptup.org/pub/stefan.graenitz at gmail.com Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. ------------...

...on overflow", >> file \lib\executionengine\runtimedyld\Targets/RuntimeDyldCOFFX86_64.h, line >> 81 >> >> It's a limitation of the COFF/PE format and unrelated to exceptions. This >> patch explains it and shows a workaround: >> >> https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f >> >> Is there no hope left? >> >> Well at least I am not aware of a solution. >> >> Am 28.09.17 um 16:04 schrieb bjoern.gaier at horiba.com: >> >> Hello Stefan, >> >> I'm happy s...

Dear all, I am using LLVM C++ API to generate some code. In particular, I am dealing with AVX2 SIMD API which uses __m256i. My function input types a set of vectors and return type is also a vector. /////////////////////////////////////////////////////////////////////////////////////////// arguments.push_back(VectorType::get(IntegerType::getIntNTy(TheContext, 64), 4));//int64*4 = __m256i

...gt; function like so: [3] > > Hope it helps. > > Cheers, > Stefan > > [1] https://llvm.org/docs/LangRef.html#vector-type > [2] https://en.cppreference.com/w/cpp/container/vector > [3] https://en.cppreference.com/w/cpp/container/vector/data > [4] > https://github.com/weliveindetail/DecisionTreeCompiler/blob/master/compiler/DecisionTreeCompiler.cpp#L83 > > Am 20.07.18 um 02:02 schrieb Jia Yu via llvm-dev: > > Dear all, > > I am using LLVM C++ API to generate some code. In particular, I am dealing > with AVX2 SIMD API which uses __m256i. > > My functi...

...>> line >> >> 81 >> >> >> >> It's a limitation of the COFF/PE format and unrelated to exceptions. >> >> This >> >> patch explains it and shows a workaround: >> >> >> >> >> >> https://github.com/weliveindetail/pj-llvm/commit/97cd336d458ae9c73232d1b539ceefcdb2f5eb0f >> >> >> >> Is there no hope left? >> >> >> >> Well at least I am not aware of a solution. >> >> >> >> Am 28.09.17 um 16:04 schrieb bjoern.gaier at horiba.com: >> &g...

Hi, I know their are various tools that can take LLVM IR Bitcode and JIT it and execute it. Is there anything that can do the equivalent but at the LL\VM IR Bitcode level? So, that for example, I could set some initial conditions, and then single step through the IR Bitcode function, and pause it and print out any of the SSA values that I wish? Kind Regards James

...gt; function like so: [3] > > Hope it helps. > > Cheers, > Stefan > > [1] https://llvm.org/docs/LangRef.html#vector-type > [2] https://en.cppreference.com/w/cpp/container/vector > [3] https://en.cppreference.com/w/cpp/container/vector/data > [4] > https://github.com/weliveindetail/DecisionTreeCompiler/blob/master/compiler/DecisionTreeCompiler.cpp#L83 > > Am 20.07.18 um 02:02 schrieb Jia Yu via llvm-dev: > > Dear all, > > > > I am using LLVM C++ API to generate some code. In particular, I am dealing > with AVX2 SIMD API which uses __m256i. > >...

...info/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- https://weliveindetail.github.io/blog/ https://cryptup.org/pub/stefan.graenitz at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171123/edeb05ed/attachment.html> -------------- next part -------------- A non-text att...

Tried that, still didn't work. Then I tried making a direct API call, GetProcAddress(GetModuleHandle(0),"foo") And this works if and only if __declspec(dllexport) is supplied. So it looks like we were both right. On Sat, Apr 2, 2016 at 9:29 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Have you tried to add dllexport? > > On Sat, Apr 2, 2016 at 4:23 PM