* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
@ 2021-12-13 15:28 ` seurer at gcc dot gnu.org
2021-12-13 17:06 ` redi at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: seurer at gcc dot gnu.org @ 2021-12-13 15:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #1 from seurer at gcc dot gnu.org ---
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
2021-12-13 15:28 ` [Bug libstdc++/103687] " seurer at gcc dot gnu.org
@ 2021-12-13 17:06 ` redi at gcc dot gnu.org
2021-12-13 17:12 ` seurer at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-13 17:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2021-12-13
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
They were all failing on gcc112 (ppc64le) for me earlier today, but I haven't
debugged it yet.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
2021-12-13 15:28 ` [Bug libstdc++/103687] " seurer at gcc dot gnu.org
2021-12-13 17:06 ` redi at gcc dot gnu.org
@ 2021-12-13 17:12 ` seurer at gcc dot gnu.org
2021-12-13 22:10 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: seurer at gcc dot gnu.org @ 2021-12-13 17:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #3 from seurer at gcc dot gnu.org ---
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?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2021-12-13 17:12 ` seurer at gcc dot gnu.org
@ 2021-12-13 22:10 ` jakub at gcc dot gnu.org
2021-12-14 11:41 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-12-13 22:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'll have a look tomorrow.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2021-12-13 22:10 ` jakub at gcc dot gnu.org
@ 2021-12-14 11:41 ` jakub at gcc dot gnu.org
2021-12-14 11:47 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-12-14 11:41 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2021-12-14 11:41 ` jakub at gcc dot gnu.org
@ 2021-12-14 11:47 ` jakub at gcc dot gnu.org
2021-12-14 13:27 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-12-14 11:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2021-12-14 11:47 ` jakub at gcc dot gnu.org
@ 2021-12-14 13:27 ` jakub at gcc dot gnu.org
2021-12-14 14:44 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-12-14 13:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (6 preceding siblings ...)
2021-12-14 13:27 ` jakub at gcc dot gnu.org
@ 2021-12-14 14:44 ` redi at gcc dot gnu.org
2021-12-14 14:46 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-14 14:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (7 preceding siblings ...)
2021-12-14 14:44 ` redi at gcc dot gnu.org
@ 2021-12-14 14:46 ` redi at gcc dot gnu.org
2021-12-14 14:48 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-14 14:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (8 preceding siblings ...)
2021-12-14 14:46 ` redi at gcc dot gnu.org
@ 2021-12-14 14:48 ` redi at gcc dot gnu.org
2021-12-14 16:15 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-14 14:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (9 preceding siblings ...)
2021-12-14 14:48 ` redi at gcc dot gnu.org
@ 2021-12-14 16:15 ` redi at gcc dot gnu.org
2021-12-14 23:37 ` cvs-commit at gcc dot gnu.org
2021-12-14 23:39 ` redi at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-14 16:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|NEW |ASSIGNED
Target Milestone|--- |12.0
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (10 preceding siblings ...)
2021-12-14 16:15 ` redi at gcc dot gnu.org
@ 2021-12-14 23:37 ` cvs-commit at gcc dot gnu.org
2021-12-14 23:39 ` redi at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-12-14 23:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898
2021-12-13 15:26 [Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898 seurer at gcc dot gnu.org
` (11 preceding siblings ...)
2021-12-14 23:37 ` cvs-commit at gcc dot gnu.org
@ 2021-12-14 23:39 ` redi at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-14 23:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 14+ messages in thread