[Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898

[Bug libstdc++/103687] New: [12 regression] several time/date failures after r12-5898

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103687

            Bug ID: 103687
           Summary: [12 regression] several time/date failures after
                    r12-5898
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:c82e492616e343b6d6db218d2b498267bac899de, r12-5898

FAIL: 22_locale/time_get/get/char/3.cc execution test
FAIL: 22_locale/time_get/get/char/3.cc execution test
FAIL: 22_locale/time_get/get/wchar_t/3.cc execution test
FAIL: 22_locale/time_get/get/wchar_t/3.cc execution test
FAIL: 22_locale/time_get/get_date/char/12791.cc execution test
FAIL: 22_locale/time_get/get_date/char/12791.cc execution test
FAIL: 22_locale/time_get/get_date/wchar_t/12791.cc execution test
FAIL: 22_locale/time_get/get_date/wchar_t/12791.cc execution test
FAIL: 22_locale/time_get/get_time/char/2.cc execution test
FAIL: 22_locale/time_get/get_time/char/2.cc execution test
FAIL: 22_locale/time_get/get_time/char/5.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_env.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_locale.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/2.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/5.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_env.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test

The error seems to be this:
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/22_locale/time_get/get_time/wchar_t/2.cc:62:
void test02(): Assertion 'errorstate == ios_base::eofbit' failed.

This is a powerpc64 big endian system and it fails for both 32 and 64 bit runs.
 This update works fine on powerpc64 little endian.

commit c82e492616e343b6d6db218d2b498267bac899de
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Dec 10 17:01:28 2021 +0100

    libstdc++: Some time_get fixes [PR78714]

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[seurer at gcc dot gnu.org]

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

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[seurer at gcc dot gnu.org]

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?

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[jakub at gcc dot gnu.org]

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.

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[jakub at gcc dot gnu.org]

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

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[jakub at gcc dot gnu.org]

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.

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[jakub at gcc dot gnu.org]

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.

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[redi at gcc dot gnu.org]

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

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[redi at gcc dot gnu.org]

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

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[cvs-commit at gcc dot gnu.org]

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.

[Bug libstdc++/103687] [12 regression] several time/date failures after r12-5898

[redi at gcc dot gnu.org]

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.