<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 30, 2014 at 2:10 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 30 Jan 2014, at 00:04, Nick Lewycky <<a href="mailto:nlewycky@google.com">nlewycky@google.com</a>> wrote:<br>

<br>
> This is also what many clang tests do, where TUs get parsed using the host triple. If we keep target datalayout out of the test files and fill it in with the host's information, then our test coverage expands as our buildbot diversity grows, which is a neat property.<br>

<br>
</div>Unfortunately, reproducibility suffers.  You commit a change, a test fails on two buildbots but passes on all of the others and on your local system.  Now what do you do?  I've already hit this problem in clang, with host-defined tool search paths leaking into the tests and causing them to fail on Windows only.  It's hard to fix a bug that causes a buildbot failure if you can't reproduce it.  At the very least, the target / data layout should be in the failure message that the test suite generates in case of failure so that you can reproduce it locally if a buildbot reports failure.<br>
</blockquote><div><br></div><div>I don't think this will be a problem for opt or other LLVM tools.  If opt has a dependence on the host's default triple and datalayout, reproducing the failure should be a simple matter of running the test locally with a manually specified triple.  It doesn't have implicit header search paths or other weird host dependencies.</div>
</div></div></div>