<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 3, 2013 at 11:22 AM, Tom Stellard <span dir="ltr"><<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jun 03, 2013 at 02:02:53PM -0400, Rafael Ávila De Espíndola wrote:<br>
> Test case ?<br>
><br>
Hi Rafael,<br>
<br>
There are tests for these bugs in later commits mostly<br>
work-item-intrinsics.ll<br>
<br>
Most of these bugs were uncovered while working on a new feature for the<br>
backend.  Usually when this happens I make commits like this:<br>
<br>
r1 - Bug Fix #1<br>
r2 - Bug Fix #2<br>
r3 - New Feature + Bug tests<br>
<br>
I don't like to push commits that have know bugs, even if the bug fix<br>
is coming in the next commit.  The main reason for this is to make the<br>
history more easily bisectable in case of other bugs.  Unfortunately,<br>
this meas that tests are not included in the same commit as the fixes,<br>
but I consider a cleaner history more important.<br></blockquote><div><br></div><div style>Then please indicate in the commit message that tests are forthcoming in a future patch. But really, it makes review much easier if you just include the tests with the commit.</div>
<div style><br></div><div style>-- Sean Silva </div></div></div></div>