<div dir="ltr">Hi Jon,<div><br></div><div>Thanks for all the feedback.</div><div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">I'm with Dan on this... It seems like these 'fixes' are just lowering the expectations of tests when testing against a GLIBC system. It's perfectly appropriate to XFAIL them and let them fail if that is the case.</span></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I've changed a fair amount of tests to XFAIL after Dan's advice. Are you commenting on his comments or any tests in particular?</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px">If you're concerned about test coverage being lower because though there are lots of assertions in a single test file, it only takes one failure to effectively hide the results of the others, then I think it makes more sense to find a way to split the test. That way the part that is XFAIL'd is a bit more minimal.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">I think that is the way I'll go but I'll get this patch in first. Hopefully we can get a reasonable amount of linux coverage without lowering our expectations of the tests.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div>> <span style="font-family:arial,sans-serif;font-size:13px">One more thing: You've marked a bunch of these tests as 'XFAIL: linux'. Would 'XFAIL: glibc' be more appropriate?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Yes, it would. Currently we don't have a glibc available feature. Do you know a nice way of detecting GLIBC during CMake configuration time or lit configuration time? </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">For the sake of clarity it might be worth it to add a glibc available feature whenever we are on linux but that is not any more correct.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div>Thanks for the feedback,</div><div>Eric</div><div><font face="arial, sans-serif"><br></font></div><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Aug 17, 2014 at 9:45 PM, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
<br>
On 8/17/14, 9:43 PM, Jonathan Roelofs wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 8/14/14, 9:43 PM, Dan Albert wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think I may have misled you when I said we should #ifdef the differences<br>
between glibc and Mac. If there are legitimate differences, we should #ifdef<br>
them. If glibc is wrong (it looks like it often is), we should just XFAIL the<br>
test and file a bug against glibc (or does that data come from an OS package?).<br>
</blockquote>
I'm with Dan on this... It seems like these 'fixes' are just lowering the<br>
expectations of tests when testing against a GLIBC system. It's perfectly<br>
appropriate to XFAIL them and let them fail if that is the case.<br>
<br>
If you're concerned about test coverage being lower because though there are<br>
lots of assertions in a single test file, it only takes one failure to<br>
effectively hide the results of the others, then I think it makes more sense to<br>
find a way to split the test. That way the part that is XFAIL'd is a bit more<br>
minimal.<br>
</blockquote>
<br></div>
One more thing: You've marked a bunch of these tests as 'XFAIL: linux'. Would 'XFAIL: glibc' be more appropriate?<br>
<br>
<br>
Cheers,<br>
<br>
Jon<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Cheers,<br>
<br>
Jon<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-commits</a><br>
<br>
</blockquote>
<br>
</blockquote>
<br>
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br>
</div></div></blockquote></div><br></div>