<br><br><div class="gmail_quote">On Tue, Jul 26, 2011 at 11:01 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div class="im"><br><div><div>On Jul 26, 2011, at 8:11 AM, Talin wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><blockquote type="cite"><div class="gmail_quote"><div><br>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.</div>
</div></blockquote><br></div></div><div>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.</div></div></blockquote>
<div><br></div><div>Let me try with another example: Let's say Module A and Module B both import class Exception. Class Exception has a "message" field which is a pointer to type String. Now, let's say Module A dereferences the Exception.message field by printing the message. The compiler sees this dereference, and automatically loads the String module. Type String is added to Module A as a fully-resolved struct type.</div>
<div><br></div><div>In Module B, on the other hand, there is no dereference of the message field. So the compiler includes the definition of Exception, but the definition of String is opaque, because no code in Module B ever referred to any of the fields of class String. In fact the compiler never even loaded the definition of String because it wasn't needed.</div>
<div><br></div><div>Now we attempt to link together a bunch of modules including A and B. The linker sees that there are two types named "Exception" and renamed one of them. It also sees that there are two types named "String" and renames one of those as well. At this point, the linker fails because of a type mismatch. At least, this is the behavior that I am seeing.</div>
</span></blockquote></div><br></div><div>What do you mean "the linker 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,</div>
<div><br></div></div></blockquote><div>It's llvm-ld that asserts here:</div><div><br></div><div><div>Assertion failed: (N < NumContainedTys && "Element number out of range!"), function getElementType, file /Users/talin/Projects/llvm/include/llvm/DerivedTypes.h, line 268.</div>
</div><div><br></div><div><div>5 0x0000000100158f27 in llvm::StructType::getElementType (this=0x10180f310, N=0) at DerivedTypes.h:268</div><div>#6 0x00000001001b8b54 in llvm::BitcodeReader::ParseConstants (this=0x101813800) at /Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1256</div>
<div>#7 0x00000001001be481 in llvm::BitcodeReader::ParseModule (this=0x101813800) at /Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1578</div><div>#8 0x00000001001bf8fb in llvm::BitcodeReader::ParseBitcodeInto (this=0x101813800, M=0x101605dd0) at /Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1848</div>
<div>#9 0x00000001001bf9ea in llvm::getLazyBitcodeModule (Buffer=0x10181b800, Context=@0x101600290, ErrMsg=0x7fff5fbfc8f0) at /Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:2776</div><div>#10 0x00000001001bfa7b in llvm::ParseBitcodeFile (Buffer=0x10181b800, Context=@0x101600290, ErrMsg=0x7fff5fbfc8f0) at /Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:2792</div>
<div>#11 0x000000010006cf52 in llvm::Linker::LoadObject (this=0x7fff5fbfcd50, FN=@0x101801a28) at /Users/talin/Projects/llvm/lib/Linker/Linker.cpp:107</div><div>#12 0x000000010006494e in llvm::Linker::LinkInFile (this=0x7fff5fbfcd50, File=@0x101801a28, is_native=@0x7fff5fbfcb7f) at /Users/talin/Projects/llvm/lib/Linker/LinkItems.cpp:199</div>
<div>#13 0x0000000100064c5e in llvm::Linker::LinkInFiles (this=0x7fff5fbfcd50, Files=@0x7fff5fbfce30) at /Users/talin/Projects/llvm/lib/Linker/LinkItems.cpp:238</div><div>#14 0x0000000100007c1f in main (argc=130, argv=0x7fff5fbfd1f0, envp=0x7fff5fbfd608) at /Users/talin/Projects/llvm/tools/llvm-ld/llvm-ld.cpp:582</div>
</div><div><br></div><div>I'll get you a reproducible test case in the next day or so.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">
<div></div><font color="#888888"><div>-Chris</div></font></div></blockquote></div><br>-- <br>-- Talin<br>