<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 26, 2011, at 12:54 PM, Eric Christopher wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 26, 2011, at 12:43 PM, Duncan Sands wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Eric,<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Non-determinism! The dragonegg selfhost compared object files it built<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">at different stages, and they weren't the same. I guess this might be<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">due to echristo's inline cost changes.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">... Those were Sunday though. No costs changed yesterday, might be some<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">caching effects though. I'll take a look.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I've reverted for now to see if it fixes it, but a quick question. From looking<br></blockquote><blockquote type="cite">at the output of the script it looks like it is comparing the output of<br></blockquote><blockquote type="cite">stage 0 vs the output of stage 1? Or is that just an artifact of the script?<br></blockquote><br>thanks for reverting your patch. The stages are not exactly the same as with a<br>gcc bootstrap. In stage 0, LLVM and dragonegg are built with gcc, but dragonegg<br>is then immediately rebuilt with itself, creating the object files that are used<br>for the comparison. So these object files are analogous to the object files<br>produced by stage1 of a gcc bootstrap.</blockquote></div><br><div>OK, that's a bit better. I'd like some sort of test case if you can arrange it</div><div>though. I didn't see anything in the patch that could cause this sort of issue.</div></div></blockquote><br></div><div>A preprocessed version of the miscomparing file (or even better, bitcode and</div><div>some optimization options) would be helpful at least.</div><div><br></div><div>-eric</div><br></body></html>