similar to: [LLVMdev] PointerType API Change

On Dec 16, 2007, at 10:22 PM, Anton Korobeynikov wrote: > Christopher, > >> The API for getting PointerType objects has just changed to make >> Embedded C address space information explicit. The old semantics of >> PointerType::get() now apply to PointerType::getUnqual(), which >> returns a pointer in the generic address space. PointerType::get() >> now

Would it be possible to keep get() unchanged, with a default behaviour, plus a warning? Otherwise everybody (assuming everybody gets type void*) will have to update their LLVM passes, and either maintain two versions of the passes or require their clients to use a certain LLVM version. Then passes could be "address-space-safe" or not. If the default parameter value for get() could

On Dec 17, 2007, at 1:22 AM, Torvald Riegel wrote: > Would it be possible to keep get() unchanged, with a default > behaviour, plus > a warning? Otherwise everybody (assuming everybody gets type void*) > will > have to update their LLVM passes, and either maintain two versions > of the > passes or require their clients to use a certain LLVM version. AFAIK API

On Monday 17 December 2007, Christopher Lamb wrote: > On Dec 17, 2007, at 1:22 AM, Torvald Riegel wrote: > > Would it be possible to keep get() unchanged, with a default > > behaviour, plus > > a warning? Otherwise everybody (assuming everybody gets type void*) > > will > > have to update their LLVM passes, and either maintain two versions > > of the >

The API for getting PointerType objects has just changed to make Embedded C address space information explicit. The old semantics of PointerType::get() now apply to PointerType::getUnqual(), which returns a pointer in the generic address space. PointerType::get() now requires both a type and an address space. The clang, llvm-gcc-4.0, and llvm-gcc-4.2, and internal llvm projects have all

On Dec 17, 2007, at 2:51 AM, Torvald Riegel wrote: > On Monday 17 December 2007, Christopher Lamb wrote: >> On Dec 17, 2007, at 1:22 AM, Torvald Riegel wrote: >>> Would it be possible to keep get() unchanged, with a default >>> behaviour, plus >>> a warning? Otherwise everybody (assuming everybody gets type void*) >>> will >>> have to update

On 2007-12-17, at 00:31, Christopher Lamb wrote: > The API for getting PointerType objects has just changed to make > Embedded C address space information explicit. The old semantics of > PointerType::get() now apply to PointerType::getUnqual(), which > returns a pointer in the generic address space. PointerType::get() > now requires both a type and an address space. >

Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =

I recently began hacking around with my first LLVM pass. The big picture is that I would like to insert function calls for each instruction type, and pass some parameters based on the instruction type. Then I will link the output to some C file that implements those functions. Things were going well until I started trying to make function calls with a pointer as a parameter. For example, I would

Hi Evan, > LValue LV = EmitLV(lhs); > bool isVolatile = TREE_THIS_VOLATILE(lhs); > unsigned Alignment = expr_align(exp) / 8 > > It's using the alignment of the expression, rather than the memory > object of LValue. can't you just use expr_align(lhs) instead? > The patch saves the alignment of the memory object in LValue returned > by EmitLV().

I feel a bit bad for always asking beginner questions here but I am having some difficulties with a runtime error with which I could use some help diagnosing. 1) I am getting the assertion failure main: Type.cpp:1309: static llvm::PointerType* llvm::PointerType::get(const llvm::Type*, unsigned int): Assertion `ValueType && "Can't get a pointer to <null> type!"'

Carter Cheng wrote: > I feel a bit bad for always asking beginner questions here but I am having some difficulties with a runtime error with which I could use some help diagnosing. > > 1) I am getting the assertion failure > > main: Type.cpp:1309: static llvm::PointerType* llvm::PointerType::get(const llvm::Type*, unsigned int): Assertion `ValueType && "Can't

Hi Victor, this code from the verifier broke the Ada front-end build: const Module* M = CI.getParent()->getParent()->getParent(); Constant *MallocFunc = M->getFunction("malloc"); if (CI.getOperand(0) == MallocFunc) { const PointerType *PTy = PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext())); Assert1(CI.getType() == PTy, "Malloc

On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > I've been playing around with clang/LLVM looking at adding partial > support for the draft technical report for embedded C extensions > (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ > n1169.pdf), specifically named address spaces. > > Named address spaces need to be tracked in LLVM in essentially all

> Nope, types are immutable once created. The only thing you can do is "refine" opaque types to other types. There is a section in the programmer's manual on this: > http://llvm.org/docs/ProgrammersManual.html#TypeResolve > > -Chris So I succeeded in using a "PATypeHolder" for the "opaque" type, define a Type* with PointerType::getUnqual, prepare

On Sep 22, 2009, at 4:49 PM, Talin wrote: > > // Calculate the size of the specified LLVM type. > Constant * DebugInfoBuilder::getSize(const Type * type) { > Constant * one = ConstantInt::get(Type::Int32Ty, 1); > return ConstantExpr::getPtrToInt( > ConstantExpr::getGetElementPtr( > ConstantPointerNull::get(PointerType::getUnqual(type)), >

Hello, I'm wondering if it's possible to dereference a PointerType. I have an AllocaInst and although I can find the number of elements allocated, (using Instruction::getOperand(0)), I can't find a way to get the size of each element. What I'd like to do is: AllocaInst *alloca; PointerType *ptr_type = dynamic_cast<PointerType*>(alloca); assert(ptr_type); Type

That seems to work, thanks! The specific code I ended up with to call int64_t print(int64_t) looks like: auto f = builder.CreateIntToPtr( ConstantInt::get(builder.getInt64Ty(), uintptr_t(print)), PointerType::getUnqual(FunctionType::get( builder.getInt64Ty(), {builder.getInt64Ty()}, false))); return builder.CreateCall(f, args); On Mon, Mar

I agree, improving this makes sense. Alexander, I don’t think that “LLVM_DEFAULT_AS_PARAM” is the right way to go, I would just remove the “ = 0” default parameter entirely. -Chris > On Jul 23, 2020, at 11:02 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Alex, > > I'd be very much in favor of this, thanks for pushing ;) > > On Wed,

The line comes up on a back trace using gdb. I think it's the right line (I have tried it on two separate machines one using Fedora 11 and g++ 4.4.x and the other Ubunto and g++ 4.3.3) and the situation is exceptionally odd since it only occurs when compiling my Runtime.cpp and doesnt happen when compiling other files. This is with LLVM 2.5. I did look at the Type.cpp code and it should be