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 been updated to take this API change into account. The only current omission is the C interface to the LLVM type system, which has not yet been updated to preserve or expose address spaces on PointerType's. I'm hoping for a little help with that. Thanks -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071216/3cef5847/attachment.html>
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. > > The clang, llvm-gcc-4.0, and llvm-gcc-4.2, and internal llvm > projects have all been updated to take this API change into account. > > The only current omission is the C interface to the LLVM type > system, which has not yet been updated to preserve or expose address > spaces on PointerType's. I'm hoping for a little help with that.I've already written that locally and am updating the Ocaml bindings, so don't worry that point much. — Gordon
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. > > The clang, llvm-gcc-4.0, and llvm-gcc-4.2, and internal llvm > projects have all been updated to take this API change into account. > > The only current omission is the C interface to the LLVM type > system, which has not yet been updated to preserve or expose address > spaces on PointerType's. I'm hoping for a little help with that.Hi Cristopher, I ran aground of this mildly: $ Release/bin/llvm-as <<END_OF_LL | Release/bin/llvm-dis %Gnric = type i8* %Qual3 = type i8 addrspace(3)* %Qual5 = type i8 addrspace(5)* END_OF_LL ; ModuleID = '<stdin>' %Gnric = type i8* %Qual3 = type i8* %Qual5 = type i8* It looks to be purely a problem in llvm-dis output since the three types would fold internally to the llvm-dis process if the qualifiers did not survive through the input phase. Please revert r45097 when you get this working. Thanks! Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071217/fbf360c9/attachment.html>
On Dec 17, 2007, at 8:17 AM, Gordon Henriksen wrote:> 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. >> >> The clang, llvm-gcc-4.0, and llvm-gcc-4.2, and internal llvm >> projects have all been updated to take this API change into account. >> >> The only current omission is the C interface to the LLVM type >> system, which has not yet been updated to preserve or expose >> address spaces on PointerType's. I'm hoping for a little help with >> that. > > Hi Cristopher, > > I ran aground of this mildly: > > $ Release/bin/llvm-as <<END_OF_LL | Release/bin/llvm-dis > %Gnric = type i8* > %Qual3 = type i8 addrspace(3)* > %Qual5 = type i8 addrspace(5)* > END_OF_LL > ; ModuleID = '<stdin>' > %Gnric = type i8* > %Qual3 = type i8* > %Qual5 = type i8* > > It looks to be purely a problem in llvm-dis output since the three > types would fold internally to the llvm-dis process if the > qualifiers did not survive through the input phase. > > Please revert r45097 when you get this working.Fixed http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of- Mon-20071217/056441.html -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071217/10c2f614/attachment.html>