https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- On gcc110 (which is BE), I certainly can't reproduce the 3.cc failures you see. All I see is (both -m32 and -m64): +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 and the reason for that is simple, old glibc. On gcc110 with glibc 2.17 one gets: LC_ALL=en_HK locale -k LC_TIME | grep _fmt | grep -v era d_t_fmt="%A, %B %d, %Y %p%I:%M:%S %Z" d_fmt="%A, %B %d, %Y" t_fmt="%I:%M:%S %Z" t_fmt_ampm="%p%I:%M:%S %Z" date_fmt="%a %b %e %H:%M:%S %Z %Y" While on glibc 2.32 I get: LC_ALL=en_HK locale -k LC_TIME | grep _fmt | grep -v era d_t_fmt="%A, %B %d, %Y %p%I:%M:%S" d_fmt="%A, %B %d, %Y" t_fmt="%I:%M:%S %p %Z" t_fmt_ampm="%I:%M:%S %p %Z" date_fmt="%A, %B %d, %Y %p%I:%M:%S %Z" r12-5898 changed the testcase to match the recent glibc locale data: https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=libstdc%2B%2B-v3/testsuite/22_locale/time_get/get_time/char/2.cc;h=a847748dc2716c7073bf7e6a2c5be8d1fefbf21c;hp=79f921d1cf6795e242f590cb8062a738c742884c;hb=c82e492616e343b6d6db218d2b498267bac899de;hpb=57b291c27ee7b2b2e6c04c37ec1b8f5bf87b99c4 previously it was failing on recent glibc and not on the old one. One option to fix this would be custom locales where we don't have to chase what exactly glibc of the day locales contain. Another would be to use the non-standard _M_time_formats method on the __timepunct facet of the locale, check what that string contains and based on that decide what exactly to do in the test. Another one would be to use the C APIs to query it (setlocale and nl_langinfo).
