Displaying 7 results from an estimated 7 matches for "gvswithcod".
Did you mean:
gvswithcode
2009 Oct 06
4
[LLVMdev] 2.6/trunk Execution Engine question
> 6. When ExecutionEngine::create was called with parameter
> "GVsWithCode" set to its default value of true, I got a segfault when
> trying to get a pointer to one of my globals. JIT::getMemoryForGV was
> returning NULL in that case. Explicitly passing false for
> "GVsWithCode" cleared it up.
That's no good. Could you send me a stack trac...
2009 Oct 06
0
[LLVMdev] 2.6/trunk Execution Engine question
...have no name.
> Updating my linkage enum port cleared that up for me.
>
> 4. The set of library names to link against has changed considerably.
>
> 5. C bindings to ExecutionEngine stuff have moved out of libCore.a.
>
6. When ExecutionEngine::create was called with parameter
"GVsWithCode" set to its default value of true, I got a segfault when
trying to get a pointer to one of my globals. JIT::getMemoryForGV was
returning NULL in that case. Explicitly passing false for
"GVsWithCode" cleared it up.
2009 Oct 06
0
[LLVMdev] 2.6/trunk Execution Engine question
On Tue, Oct 6, 2009 at 4:15 PM, Reid Kleckner <rnk at mit.edu> wrote:
>> 6. When ExecutionEngine::create was called with parameter
>> "GVsWithCode" set to its default value of true, I got a segfault when
>> trying to get a pointer to one of my globals. JIT::getMemoryForGV was
>> returning NULL in that case. Explicitly passing false for
>> "GVsWithCode" cleared it up.
>
> That's no good. Could you...
2009 Oct 06
1
[LLVMdev] 2.6/trunk Execution Engine question
My front-end is humming along beautifully now with the LLVM trunk. A
few upgrade notes for anyone who is interested:
1. Not surprisingly, everything in your front-end needs to be
recompiled; object layouts have changed. My generated code was
calling some name-mangled stuff in the C++ libraries, and using
struct/class definitions defined therein, and it fell over hard when I
ran it against the
2012 Aug 09
1
[LLVMdev] question about ExectuionEngine::Create
...n" in linux (the same code executes OK in windows):
Below is a snippet extracted from this method,
if (UseMCJIT && ExecutionEngine::MCJITCtor) {
ExecutionEngine *EE =
ExecutionEngine::MCJITCtor(M, ErrorStr, JMM, OptLevel,
AllocateGVsWithCode, TM);
if (EE) return EE;
} else if (ExecutionEngine::JITCtor) {
ExecutionEngine *EE =
ExecutionEngine::JITCtor(M, ErrorStr, JMM, OptLevel,
AllocateGVsWithCode, TM);
if (EE) return EE;
}
Both ExecutionEngine::MCJITCto...
2009 Oct 06
3
[LLVMdev] 2.6/trunk Execution Engine question
On Mon, Oct 5, 2009 at 8:27 PM, Axel Naumann <Axel.Naumann at cern.ch> wrote:
> Hi,
>
> #include "JIT.h" will do.
Thanks. That was exactly what I needed to progress to the next error
("Unable to find target for this triple (no targets are registered)")
As soon as I get this front-end working with the trunk, I'll start
submitting patches that add calls to
2009 Dec 25
1
[LLVMdev] JIT buffer code skipping 8 bytes?
On OS X (10.6.2) running on an Intel Core 2 duo with LLVM 2.7 pulled about a month ago from CVS and built in debug mode:
Using the JIT system with exception handling, I am having issues with type infos. "Finally" code (llvm.eh.selector intrinsic call with 0)
works fine (correct landing pads found), as does this call with one type info. My type infos are each 64 bit array GlobalVariables