similar to: [LLVMdev] ConstantPointerRef and void*'s to functions

As I thought about this more, I realized that the problem is not as easy as just transmuting the FunctionType from one FunctionType 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

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

On Thu, 17 Jun 2004, Patrick Meredith wrote: > 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, >

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*>

Hi Mitnick, > === Overview === > > The general concept is to replaced void with {}. And 'ret void' is a synonym of > 'ret {} {}.' in a sense the concept is just to delete void and not to replace it with anything in particular. Of course front-ends (clang, dragonegg) need to produce something instead of void, and {} is an example of what they might produce, but they

Hello all, I am willing to do "eliminating the void type" project. Is there anyone working on it? === Overview === The general concept is to replaced void with {}. And 'ret void' is a synonym of 'ret {} {}.' === Further Implementation Details === 1. Deleting VoidTyID 2. Deleting LLVMVoidTypeKind (one-to-one relation between VoidTyID and LLVMVoidTypeKind) 3. Use

On 5/7/12 10:36 AM, Duncan Sands wrote: > Hi Mitnick, > >> === Overview === >> >> The general concept is to replaced void with {}. And 'ret void' is a synonym of >> 'ret {} {}.' > in a sense the concept is just to delete void and not to replace it with > anything in particular. Of course front-ends (clang, dragonegg) need to produce >

Hello Chris, The general concept is to replace void with {}. Void is a weird type in > that it is only allowed as the return value of functions and as the type of > instructions like store. It seems better (though also not particularly > high priority) to eliminate it to make the type system more consistent. > > -Chris > I also noticed a sentence "We can even make

Hello Duncan, There is a discussion with Chris Lattner: http://old.nabble.com/Eliminating-the-'void'-type-td33726468.html In the discussion, Chris Lattner suggest Type::getVoidTy() should still exist and return {} for API continuity. If VoidTy and isVoidTy() go away, how do deal with the isVoidTy() function call in LLVM source tree? Another issue is: What should ReturnInst constructor

Hi Dan, >> I am willing to do "eliminating the void type" project. > > Is this really a good idea? I'm not going to argue at length > about it, but it is worth thinking about. > > The only practical downsides of void are when newcomers take C's > syntax for functions with no arguments a little too literally, or > when they try to create pointers to

Hello all, I noticed Eliminating the 'void' type<http://nondot.org/sabre/LLVMNotes/EliminatingVoid.txt>in Random LLVM notes. I am wondering to know what's the meaning of "eliminating" the void type. Is it means the goal is deleting VoidTyID from TypeID enumeration in Type.h? And what Type::getVoidTy() returned is a pointer to a {}? Thanks Mitnick -------------- next

On Apr 21, 2012, at 12:17 PM, Lyu Mitnick wrote: > Hello all, > > I noticed Eliminating the 'void' type in Random LLVM notes. I am wondering to know what's the > meaning of "eliminating" the void type. Is it means the goal is deleting VoidTyID from TypeID > enumeration in Type.h? And what Type::getVoidTy() returned is a pointer to a {}? The general concept

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

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

LLVMers, On the way to resolving bug 122, I am committing my SymbolTable rewrite. If you are working on anything that uses the SymbolTable, I suggest you read the documentation in include/llvm/SymbolTable.h. The changes I've committed reduce the use of Type::TypeTy. This static member will go away in the future, so please do not propagate new code that uses it. There is no reason to use it

Thank you Chris, for your hint, but I am still too stupid. I tried two versions asm_arguments.push_back(Type::VoidTy); FunctionType *asm_type = FunctionType::get(Type::VoidTy, asm_arguments, false); Alternatively FunctionType *asm_type = FunctionType::get(Type::VoidTy, std::vector<const Type*>(), false); . Can you give me a snippet of example code, or somebody else?

Hi, I' am trying to insert an InlineAsm Instruction in my pass, which FunctionType do I need for Inlineasm? If I understand it right, I need a call instruction to insert the new produced InlineAsm? Thanks for help, Michael for (BasicBlock::iterator bi = i->begin(), be = i->end(); bi != be; ++bi){ std::vector<const Type*> asm_arguments;

On Jul 31, 2009, at 10:24 AM, Michael Graumann wrote: > Hi, > I’ am trying to insert an InlineAsm Instruction in my pass, which > FunctionType do I need for Inlineasm? > If I understand it right, I need a call instruction to insert the > new produced InlineAsm? > > Thanks for help Inline asm works like a "callee". So for: call void asm sideeffect

Dmitry, > This is probably a question for Fortran/DragonEGG experts: > > Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* > @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ? Why it needs > bitcast? Just a wild guess (basing from my llvm-gcc knwoledge though): there is a bug with in gcc fortran frontend where it fails to

Hi Anton, >> How do you think what would be the best way to workaround this problem, if >> it seems to be not in focus for anybody for now? > Keep in mind, this not LLVM problem, it's gfortran problem. Also, it's > of pretty low priority for gcc devs since they do almost no type > checking on TREEs, so the varargs decl seems to be only viable > llvm-side fix.