search for: numcontainedtys

...fails"? Type mismatches should not cause the linker to fail. In any case, this example should link, please provide a minimal example of two .ll files that repros what you're seeing with llvm-link. Thanks, > > It's llvm-ld that asserts here: > > Assertion failed: (N < NumContainedTys && "Element number out of range!"), function getElementType, file /Users/talin/Projects/llvm/include/llvm/DerivedTypes.h, line 268. > Sounds like a bug, thanks. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/p...

...s"? Type mismatches should not cause the > linker to fail. In any case, this example should link, please provide a > minimal example of two .ll files that repros what you're seeing with > llvm-link. Thanks, > > It's llvm-ld that asserts here: Assertion failed: (N < NumContainedTys && "Element number out of range!"), function getElementType, file /Users/talin/Projects/llvm/include/llvm/DerivedTypes.h, line 268. 5 0x0000000100158f27 in llvm::StructType::getElementType (this=0x10180f310, N=0) at DerivedTypes.h:268 #6 0x00000001001b8b54 in llvm::BitcodeReade...

On Jul 26, 2011, at 8:11 AM, Talin wrote: >> >> If that's true, then it means that we're back to the case where every type has to be fully defined down to the leaf level. > > I'm not sure what you mean. LLVM is perfectly fine with opaque structs so long as you don't "deference" them, GEP into them, need their size, etc. > > Let me try with

..._M_impl = {<std::allocator<llvm::AbstractTypeUser*>> = {<__gnu_cxx::new_allocator<llvm::AbstractTypeUser*>> = {<No data fields>}, <No data fields>}, _M_start = 0x921f726, _M_finish = 0x921a090, _M_end_of_storage = 0x921e898}}, <No data fields>}, NumContainedTys = 153198753, ContainedTys = 0x89f3aac} Thanks for the help. Regards Rajesh

...))) Please use V->getType()->isInteger(32) which is probably new since you started your patch. +UnionType::UnionType(LLVMContext &C, const std::vector<const Type*> &Types) + : CompositeType(C, UnionTyID) { + ContainedTys = reinterpret_cast<PATypeHandle*>(this + 1); + NumContainedTys = Types.size(); + bool isAbstract = false; + for (unsigned i = 0; i < Types.size(); ++i) { No need to evaluate Types.size() every time through the loop. +bool LLParser::ParseUnionType(PATypeHolder &Result) { ... + if (!EatIfPresent(lltok::lbrace)) { + return Error(EltTyLoc, "...

This patch adds a UnionType to DerivedTypes.h. It also adds code to the bitcode reader / writer and the assembly parser for the new type, as well as a tiny .ll test file in test/Assembler. It does not contain any code related to code generation or type layout - I wanted to see if this much was acceptable before I proceeded any further. Unlike my previous patch, in which the Union type was

...Integer(32) which is probably new since you > started your patch. > > > +UnionType::UnionType(LLVMContext &C, const std::vector<const Type*> > &Types) > + : CompositeType(C, UnionTyID) { > + ContainedTys = reinterpret_cast<PATypeHandle*>(this + 1); > + NumContainedTys = Types.size(); > + bool isAbstract = false; > + for (unsigned i = 0; i < Types.size(); ++i) { > > No need to evaluate Types.size() every time through the loop. > > > +bool LLParser::ParseUnionType(PATypeHolder &Result) { > ... > + if (!EatIfPresent(lltok::lbrac...

Hi all, We're hitting some walls here when generating the correct structure layout for specific C++ ABI requirements, and I was wondering how much StructLayout could help. For instance, the ABI has some complicated rules on the size of derived classes (http://www.codesourcery.com/public/cxx-abi/abi.html#class-types) and LLVM struct type cannot reflect that in full. Example: // CHECK: