search for: constantpointerref

I was about to post a bug concerning this, but I thought I'd check with you folks first. The symptom is a SIGSEGV in my program in the standard library template for red black trees (bits/stl_tree.h). The crash occurs as the result of an LLVM Module method, getConstantPointerRef which looks like: // Accessor for the underlying GlobalValRefMap... ConstantPointerRef *Module::getConstantPointerRef(GlobalValue *V){ // Create ref map lazily on demand... if (GVRefMap == 0) GVRefMap = new GlobalValueRefMap();...

LLVMers, The long awaited conclusion of bug 122 (VMCore cleanups) is very near. I have just committed all the changes to rid LLVM of the ConstantPointerRef abomination. This class no longer exists. Just use GlobalValue, GlobalVariable or Function directly. The changes pass 100% of Feature and Regression tests. Two minor discrepancies against the Programs tests were detected but these were attributed to either the test program (changes committed)...

...of this function into a global variable initializer (really, into the initializer of a particular structure field). The structure field type is void*, and must be. Because of type constraints, doing something like: Function* foo = ...; std::vector<const Type*> fields; ... fields.push_back(ConstantPointerRef::get(foo)); will yield a type error because the type of the function foo ("void (*) (double*, double*)") does not match the structure field type. How might I go about making the necessary cast-like step at the GlobalValue/Function level? I want to do something like: Function* quasiCast...

...nctionType to another, since void* is not a FunctionType. If the strict type-checking that is happening (the assert on Constants.cpp:233 in the ConstantStruct constructor) is the only problem here, and nothing more severe, perhaps the client should be able to set a flag that forces a the type of a ConstantPointerRef of a Function equal to what is returned by PointerType::get(Type::VoidTy), or some such thing. :) Thanks again, -j -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20030509/6b822bd6/attachment.html>

...ine here is masking the bug. In particular, you can't use the address of global variables as constants (yet: see PR122). This is definitely a bug in LLVM that you can't do this, but we do have a gross work-around. In particular, to get the address of a global value as a constant, use the ConstantPointerRef class: Constant *strconst = ConstantPointerRef::get(str); Constant *gep = ConstantExpr::getGetElementPtr(strconst, indices); In the future, the GlobalValue class will derive from the Constant class, making this unnecessary. Since the "value" of a GlobalValue is the *address* of the glo...

How is this done? Everything logical I have tried has failed, here was one attempt: Constant *C = (Constant*) ConstantArray::get(inst2string(I)); //fucnction defined elsewhere //generates a correct Global string GlobalVariable *str = new GlobalVariable(C->getType(), true, GlobalValue::InternalLinkage, C, mkStrName( strNumber++ ), &M); std::vector<Value*>

...this week. Next steps on bug 122 (each a separate commit): * Completely rid ourselves of Type::TypeTy. This involves a rewrite of the SlotCalculator which will be divided up between Bytecode writer and ASM writer. * Make Type not inherit from Value and fix the resulting fall out. * Get rid of ConstantPointerRef. If you have *any* questions about this, please email me. Thanks, Reid. Here's the Feature/Regression test results: --- STATISTICS --------------------------------------------------------------- 902 tests total 874 ( 97%) tests as expected 27 ( 3%) tests unexpecte...

Chris Lattner wrote: > > And why isn't it possible to just make those functions known to LLVM? > > After all, *I think*, if this function is to be called, it should be > > declared in assembler, and so you have to pass some information abou > > those function to the code printer. (Of course, it's possible to just > > directly print the declarations, but