On 8/17/14, 9:52 PM, Eric Fiselier wrote:
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?
Mostly agreeing with his comments after having skimmed the first patch.
I had a look at the latest version of the patch, and there is only one that
still sticks out: In put_long_double.pass.cpp you've noticed that glibc prints
NaNs with a sign depending on showpos/noshowpos, but in other implementations
that is not the case. Is this implementation defined behavior, or is one of the
two libc's doing it incorrectly?
Other than that, it looks like you've taken care of all the things I was
originally concerned about.
> 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?
I don't know of a good way to detect that. Dan might, however.
The best I can think of is to do something like:
`$CC -E -dM foo.c` | grep __GLIBC__
where foo.c includes some libc header, and then use that to decide on the
feature, but that quickly turns into the mess that is auto-fu's configure.
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.
Agreed :)
Thanks for the feedback,
Eric
On Sun, Aug 17, 2014 at 9:45 PM, Jonathan Roelofs <[email protected]
<mailto:[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] <mailto:[email protected]>
http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-commits
<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
--
Jon Roelofs
[email protected] <mailto:[email protected]>
CodeSourcery / Mentor Embedded
--
Jon Roelofs
[email protected]
CodeSourcery / Mentor Embedded
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
