<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 4, 2015, at 8:43 AM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" class="">rafael.espindola@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">> Our current issue is not reading old bitcode but what to do with new bitcode.<br class="">
><br class="">
> For instance you install a beta version of Xcode, build a project with LTO, and then revert Xcode to the previous version.<br class="">
> At this point the bitcode on your disk is too new for your installed toolchain and a non-clean build may crash libLTO.</p><p dir="ltr" class="">That is a bug in llvm. It should never crash on any input. A newer bitcode is just a special case.</p></div></blockquote><div><div>We just had a case with "ld: could not reparse object file ./libXXXX.a): 'Invalid record', using libLTO version 'Apple LLVM X.X.X (clang-X.X.X)' for architecture XYZ”. For two versions pretty close (<1y). </div><div class=""><br class=""></div></div><div>What about when LLVM 4.0 will be here? What if some 4.0 bitcode is fed through LLVM 3.8?</div><div><br class=""></div><div>Even if we don’t crash on the Bitcode *format*, which shouldn’t really happen, what about the optimizer generating intrinsics that are not supported by the backend? Admittedly the latter can be solved with global metadata.</div><div><br class=""></div><div>Also, we are branching at different interval than open-source LLVM, so the guarantee on the bitcode from a version to another might be harder to enforce (cf the message above).</div><div><div><br class=""></div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">I am confident we can get there by fuzz testing.</p></div></blockquote><div>Good idea!</div><br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">> Another case is when some people distribute static archive that contains bitcode. Right now we end-up with terrible crash reports while we want to improve user experience with great diagnostics.</p><p dir="ltr" class="">With what we have in trunk we should be able to implement errors like:</p><p dir="ltr" class="">Error: unknown linkage number XX. Input is likely from a newer llvm version. </p><p dir="ltr" class="">Would that be sufficient? </p></div></blockquote></div><br class=""><div class="">Possibly, can you point me to the mechanism involved here?</div><div class=""><br class=""></div><div class=""><div>— </div><div>Mehdi</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""></div></blockquote></div></body></html>