similar to: [LLVMdev] wrong value with getPointerToGlobal

Hi all, are there any plans to correct/implement the "getPointerToGlobal()" method for accessing global variables that are emitted by MCJIT? (see for details the unit test of MCJIT) Best Regards Armin

As far as I know, no one is working to fix the test case in question. Patches welcome :) Cheers, Dan On 2012-11-13, at 1:29 AM, "Armin Steinhoff" <armin at steinhoff.de> wrote: > > Hi all, > > are there any plans to correct/implement the "getPointerToGlobal()" method for accessing global variables that are emitted by MCJIT? > (see for details the

Hi I've written the following program: #include <R.h> #include <Rdefines.h> #include "Projector.h" SEXP Projector2(SEXP L, SEXP G, SEXP W, SEXP xymod, SEXP modif){ int nprot=0; PROTECT(L=AS_NUMERIC(L));nprot++; PROTECT(G=AS_NUMERIC(G));nprot++; PROTECT(W=AS_NUMERIC(W));nprot++; PROTECT(xymod=AS_INTEGER(xymod));nprot++; PROTECT(modif=AS_NUMERIC(modif));nprot++;

Hi My code is as following: #include <R.h> #include <Rinternals.h> //* the Projector part *// void Projector(double *L, int *dimL, double *G, int *dimG, double *W, int *dimW, int *xymod, int *dimxy, double *modif, int *dimif, double *Lsum) { ...} //* the interface part *// #define getDim(A) INTEGER(coerceVector(getAttrib(A,R_DimSymbol), INTSXP)) SEXP Projector5(SEXP L, SEXP G,

Hello! I am coming back to the below discussion again, regarding the LLVM support of Ruby dynamics. The initial problem description is as follow, to refresh your memory :) After that my questions come: -----------BEGIN Initial problem description--------------- Problem is though, that the Ruby compiler is integrated in the compilation of the program being executed, to be able to parse &

Hi all, are there any plans to correct/implement the "getPointerToGlobal()" method for accessing global variables that are emitted by MCJIT? (see for details the unit test of MCJIT) Best Regards Armin

Hi all, I need to run c++ prgrams using lli. However, I find lli cannot handle the alias instruction correctly. Following is an example: ------------ example.cc ------------- #include <iostream> using namespace std; class cls { public: cls(); ~cls(); }; cls::cls() { cout << "constructor" << endl; }; cls::~cls() { cout <<

Thanks! Problem is though, that the Ruby compiler is integrated in the compilation of the program being executed, to be able to parse & compile dynamic code at run-time. Therefore the calls to ExecutionEngine::getPointerToGlobal(F) need to be made in LLVM code. Here is a detailed simplistic example in pseudocode of what we want to do: First Ruby code is entered at run-time, received as a

> > It just occurred to me... in the case where it's failing, the > ExecutionEngine was trying to JIT a global, and it had never JITted > any functions!  I'll work up a small test case, but I think it's > relevant since the thing is trying to allocate the globals with the > functions. > That was it! The following small test program crashes in getPointerToGlobal:

leon@eatworms.swmed.edu wrote: > > I ran into a bug in samba-2.0.6: an infinite loop caused by two-level > getgrent calls. validate_group, in the middle of a getgrent loop, may > indirectly call user_in_group_list, which resets getgrent. As a result, > validate_group never exits. The attached patch works around this. It's a > quick and dirty patch which I'm including

Hello from the Military-Industrial Complex! We're a large defense contractor located in East Hartford, CT, USA. US export laws make us 'kind of' concerned about who gets in here and what they can access. We've got a problem with some of the groups that we have in our NIS database. Everyone who logs into our Sun system is assigned to one of several groups for export-control

Hi James, > want to send us your testcase code? Then we can give it a whirl. > > > Test code is at http://giantblob.com/ehtest.tar.gz > > Thanks for the help. I apologize in advance if it turns out I'm doing > something stupid! I hope you realise that by running llvm-ld without -native you are actually executing your program from the JIT. I did a native

On 12/5/12 2:49 PM, Dong Chen wrote: > here is the thing. i want to know the exact main memory address of the > Global Varibale's address when ExecutionEngine execut the *.ll code. further > more, i want to change the address, is it possible? I assume you want to adjust the value at that address, right? Then you might want to check the ExecutionEngine::getPointerToGlobal method. You

[resending since the previous copy was apparently dropped by the mailing list] >> Today I found a nice bug in the JIT global variable emitter. >> The problem may lead to an assert() failure when doing the following: >> 1) compile some function >> 2) emit a global variable >> 3) compile another function. an assert() may trigger in the JIT memory >> manager

Hi I hope this is a proper place to put my question. I've compiled Kaleidoscope from "Adding JIT and Optimizer Support" tutorial. Basically it works just fine but when I try to run extern'ed putchard function it aborts. Please, tell me what am I doing wrong? Here is more information: My PC runs FreeBSD. I've copied the toy source code exactly and didn't change it.

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > want to send us your testcase code? Then we can give it a whirl. >> >> >> Test code is at http://giantblob.com/ehtest.tar.gz >> >> Thanks for the help. I apologize in advance if it turns out I'm doing >> something stupid! >> > > I hope you realise that by

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > >> Hi James, >> >> >> want to send us your testcase code? Then we can give it a whirl. >>> >>> >>> Test code is at http://giantblob.com/ehtest.tar.gz >>> >>> Thanks for the help. I apologize in

On Oct 14, 2008, at 2:32 PM, Nuno Lopes wrote: > [resending since the previous copy was apparently dropped by the > mailing > list] > >>> Today I found a nice bug in the JIT global variable emitter. >>> The problem may lead to an assert() failure when doing the >>> following: >>> 1) compile some function >>> 2) emit a global variable

>> Today I found a nice bug in the JIT global variable emitter. >> The problem may lead to an assert() failure when doing the following: >> 1) compile some function >> 2) emit a global variable >> 3) compile another function. an assert() may trigger in the JIT memory >> manager >> >> This happens because the JIT global variable emitter is using the

Hello, I've tracked down a new memory leak which started happening when I enabled constant propagation (I created my own passmanager which I run before calling getPointerToGlobal to JIT the function I have generated - is this OK?). The reason is that FP constants are being spilled to memory as there is no immediate fp load available. In my case this is a bit unnecessary since the