[PATCH] Get all localization tests passing on linux!

[Jonathan Roelofs]

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 <jonathan at codesourcery.com
> <mailto:jonathan at codesourcery.com>> 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
>             cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>             http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-commits
>             <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
>
>
>
>     --
>     Jon Roelofs
>     jonathan at codesourcery.com <mailto:jonathan at codesourcery.com>
>     CodeSourcery / Mentor Embedded
>
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded