It looks like a couple of these fail on some LE systems, too:

FAIL: 22_locale/time_get/get_time/char/2.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test

They were all failing on gcc112 (ppc64le) for me earlier today, but I haven't debugged it yet.

Looking through all my logs I only saw those 2 failures on one little endian RHEL 8.4 power 10 machine but the BE failures on all the machines I tried.  What is on gcc112?

I'll have a look tomorrow.

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).

Note, using %I without %p (or %P) in formats certainly looks like a bug, then one can't figure out if it is am or pm time, 08:31:26 is just ambiguous.
And my patch changed also the parsing of 12 with %I, previously it would give
12 while not it gives 0 (the new way matches glibc).
With %p in addition to it is of course irrelevant, but we could revert to parsing
12 %I as 12 and when %p is specified and it is am turn it into 0.

Yet another option would be a new dg- directive (ideally something usable in effective target expressions) that would invoke (ideally remote)
LC_ALL=$second_arg locale -k $first_arg
and try to match it against the third argument (regex).  So one could verify
the assumptions the test is making,
[dg-locale-test LC_TIME "en_HK" "^t_fmt=\"%I:%M:%S %p %Z\""]
or so.

(In reply to Jakub Jelinek from comment #5)
> Another one would be to use the C APIs to query it (setlocale and
> nl_langinfo).

That's what I've done in some other tests, to workaround differences in locale data between Debian-based and other distros.

(In reply to Jakub Jelinek from comment #7)
> Yet another option would be a new dg- directive (ideally something usable in
> effective target expressions) that would invoke (ideally remote)
> LC_ALL=$second_arg locale -k $first_arg
> and try to match it against the third argument (regex).  So one could verify
> the assumptions the test is making,
> [dg-locale-test LC_TIME "en_HK" "^t_fmt=\"%I:%M:%S %p %Z\""]
> or so.

That sounds great, although if the test changes from PASS to UNSUPPORTED we're unlikely to notice, and then we just stop testing the code.

I think custom locales are the ideal solution, so we can control exactly what they contain, but I haven't found time to do it.

(In reply to Jonathan Wakely from comment #8)
> (In reply to Jakub Jelinek from comment #5)
> > Another one would be to use the C APIs to query it (setlocale and
> > nl_langinfo).
> 
> That's what I've done in some other tests, to workaround differences in
> locale data between Debian-based and other distros.

See testsuite/22_locale/time_get/get_date/wchar_t/4.cc

The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:9a4b4514bde2fe2f287f6549ef51326fb8918008

commit r12-5980-g9a4b4514bde2fe2f287f6549ef51326fb8918008
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Dec 14 22:14:48 2021 +0000

    libstdc++: Support old and new T_FMT for en_HK locale [PR103687]
    
    This checks whether the locale data for en_HK includes %p and adjusts
    the string being tested accordingly. To account for Jakub's fix to make
    %I parse "12" as 0 instead of 12, we need to change the expected value
    for the case where the locale format doesn't include %p. Also change the
    time from 12:00:00 to 12:02:01 so we can tell if the minutes and seconds
    get mixed up.
    
    libstdc++-v3/ChangeLog:
    
            PR libstdc++/103687
            * testsuite/22_locale/time_get/get_date/wchar_t/4.cc: Restore
            original locale before returning.
            * testsuite/22_locale/time_get/get_time/char/2.cc: Check for %p
            in locale's T_FMT and adjust accordingly.
            * testsuite/22_locale/time_get/get_time/wchar_t/2.cc: Likewise.

I've fixed all the failures I'm seeing, but that doesn't include all the ones listed in comment 0. Please reopen if you're still seeing FAILures.