similar to: [LLVMdev] PointerType API Change

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

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

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

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 > requires both a type and an address space. What is the reason of such change? -- With best

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

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

I could use some help here - As I use Dovecot I started here when trying to figure out why I could not add new mail folders under my Mac's Mail program, but could under Thunderbird. It was quickly pointed out that my system was set up to use MBOX and not MAILDIR, and some helpful links and notes were sent back and forth giving me a good clue as to how to perform the conversion

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,

Hi-- I'd like to stream Vorbis files from an OpenBSD 2.8 box. I followed the instructions at http://i.cantcode.com/~jack/icecast.html (via http://www.xiph.org/ogg/vorbis/index.html), and ran aground during the compilation of .../icecast/src/source.c. It needs /usr/include/ogg/{ogg,os_types,config_types}.h; /usr/include/ogg doesn't exist. I gather the directory and files

Hello all, I recently finished merging the last 3.5 months of upstream changes into our CHERI LLVM fork and would like to suggest something to both simplify our future merges and also avoid bugs for targets such as AVR that use non-zero pointer address spaces. We make extensive use of address spaces: all our pointers (CHERI capabilities) use address space 200 instead of the default zero to

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

Daniel Waterworth <da.waterworth at googlemail.com> writes: [snip] Use the getElementType method of PointerType. >> size_t size; >> if (isa<PointerType>(allocated_type)) { >> size = sizeof(void*) * 8; >> } else { >> size = allocated_type->getPrimitiveSizeInBits(); >> } >> // size now equals the size (in bits) of the type allocated

2009/10/20 Daniel Waterworth <da.waterworth at googlemail.com> > 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

Óscar Fuentes wrote: > Daniel Waterworth <da.waterworth at googlemail.com> writes: > > [snip] > > Use the getElementType method of PointerType. > >>> size_t size; >>> if (isa<PointerType>(allocated_type)) { >>> size = sizeof(void*) * 8; >>> } else { >>> size = allocated_type->getPrimitiveSizeInBits(); >>>

Seems pretty plausible to me - my only question would be whether it's worth the churn to do this intermediate step before finishing off typeless pointers (granted, I've stalled out on that for nearly a year, admittedly - but good to have extra hands/incentives - there's still a fair bit of work to do though, so understandable if it might not be useful to block progress on other things

Hi all, An oddity that has existed for a long time in the IR is that PointerType derives from SequentialType. Per subject I propose to make PointerType derive from Type for a couple of reasons: - Values of type PointerType are unlike the other SequentialTypes (arrays and vectors) in that they do not hold values of the element type. By moving PointerType we can unify certain aspects of how the

It may not be the best way to do what I'm trying to do, but it's not useless and bogus. Consider the following: %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type i32* and ; the size of that is sizeof(void *) bytes Having said that I am looking at the target data getTypeAllocSize method. Daniel 2009/10/20 Duncan Sands <baldrick at

Dear all, I have a data which is in text file and i would like to import the data to R. From the manual, i?ve found the read.table command function is the most appropriate but when i wrote the command an error had occur. It say ?Error in read.table"C:/Users/user/Documents/cfa-1.txt", header = T, sep = "\t",skip=10) :more columns than column names?. Please help me with this as

Daniel Waterworth <da.waterworth at googlemail.com> writes: > It may not be the best way to do what I'm trying to do, but it's not useless > and bogus. Consider the following: > > %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type i32* > and > ; the size of that is sizeof(void *) bytes What Duncan says is that any valid