Hi Jon, Thanks for all the feedback.
> 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. 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? > 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. 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. > One more thing: You've marked a bunch of these tests as 'XFAIL: linux'. Would 'XFAIL: glibc' be more appropriate? 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? 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. Thanks for the feedback, Eric On Sun, Aug 17, 2014 at 9:45 PM, Jonathan Roelofs <[email protected] > wrote: > > > On 8/17/14, 9:43 PM, Jonathan Roelofs wrote: > >> >> >> On 8/14/14, 9:43 PM, Dan Albert wrote: >> >>> I think I may have misled you when I said we should #ifdef the >>> differences >>> between glibc and Mac. If there are legitimate differences, we should >>> #ifdef >>> them. If glibc is wrong (it looks like it often is), we should just >>> XFAIL the >>> test and file a bug against glibc (or does that data come from an OS >>> package?). >>> >> 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. >> >> 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. >> > > One more thing: You've marked a bunch of these tests as 'XFAIL: linux'. > Would 'XFAIL: glibc' be more appropriate? > > > Cheers, > > Jon > > >> >> Cheers, >> >> Jon >> >>> >>> >>> >>> >>> _______________________________________________ >>> cfe-commits mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >>> >>> >> > -- > Jon Roelofs > [email protected] > CodeSourcery / Mentor Embedded >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
