On Wed, Mar 04, 2020 at 04:52:20AM -0800, H.J. Lu wrote:
> I saw these new failures on Fedora 31:
>
> FAIL: 22_locale/numpunct/members/char/3.cc execution test
> FAIL: 22_locale/time_get/get_time/char/2.cc execution test
> FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
As with all 22_locale tests, if something in glibc changes (usually some
locale data), some tests can fail.
Though e.g. the first test hasn't really changed since late 2018, does it
work on the trunk for you?
E.g. for the first test, seems glibc fefa21790b5081e5d04662a240e2efd18603ef86
changed:
diff --git a/localedata/locales/nl_NL b/localedata/locales/nl_NL
index d0ba6c7283..20652a9939 100644
--- a/localedata/locales/nl_NL
+++ b/localedata/locales/nl_NL
@@ -74,7 +74,7 @@ LC_MONETARY
int_curr_symbol "EUR "
currency_symbol "<U20AC>"
mon_decimal_point ","
-mon_thousands_sep "<U202F>"
+mon_thousands_sep "."
mon_grouping 3;3
positive_sign ""
negative_sign "-"
@@ -90,8 +90,8 @@ END LC_MONETARY
LC_NUMERIC
decimal_point ","
-thousands_sep ""
-grouping 0;0
+thousands_sep "."
+grouping 3;3
END LC_NUMERIC
LC_TIME
The test says:
// nl_NL chosen because it has no thousands separator (at this time).
locale loc_it = locale(ISO_8859(15,nl_NL));
so no wonder that it FAILs if nl_NL now has thousands separator.
Maybe it is time for libstdc++ testsuite to create its own artificial
locales and test against them.
Jakub
