<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 16, 2019 at 12:54 PM David Greene via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Renato Golin via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>> writes:<br>
<br>
> But if we have some consensus on doing a clean job, then I would<br>
> actually like to have that kind of intermediary check (diagnostics,<br>
> warnings, etc) on most test-suite tests, which would cover at least<br>
> the main vectorisation issues. Later, we could add more analysis<br>
> tools, if we want.<br>
<br>
I think this makes a lot of sense.<br>
<br>
> It would be as simple as adding CHECK lines on the execution of the<br>
> compilation process (in CMake? Make? wrapper?) and keep the check<br>
> files with the tests / per file.<br>
<br>
Yep.<br>
<br>
> I think we're on the same page regarding almost everything, but<br>
> perhaps I haven't been clear enough on the main point, which I think<br>
> it's pretty simple. :)<br>
<br>
Personally, I still find source-to-asm tests to be highly valuable and I<br>
don't think we need test-suite for that.  Such tests don't (usually)<br>
depend on system libraries (headers may occasionally be an issue but I<br>
would argue that the test is too fragile in that case).<br>
<br>
So maybe we separate concerns.  Use test-suite to do the kind of<br>
system-level testing you've discussed but still allow some tests in a<br>
monorepo top-level directory that test across components but don't<br>
depend on system configurations.<br></blockquote><div><br>I'm inclined to the direction suggested by others that the monorepo is orthogonal to this issue and top level tests might not be the right thing.<br><br>lldb already does end-to-end testing in its tests, for instance.<br><br>Clang does in some tests (the place I always hit is anything that's configured API-wise on the MCContext - there's no way to test that configuration on the clang boundary, so the only test that we can write is one that tests the effect of that API/programmatic configuration done by clang to the MCContext (function sections, for instance) - in some cases I've just skipped the testing, in others I've written the end-to-end test in clang (& an LLVM test for the functionality that uses llvm-mc or similar)). <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If people really object to a top-level monorepo test directory I guess<br>
they could go into test-suite but that makes it much more cumbersome to<br>
run what really should be very simple tests.<br>
<br>
                   -David<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>