Executing on host: /home/dave/gnu/gcc-4.2/objdir/./gcc/g++ -shared-libgcc -B/hom e/dave/gnu/gcc-4.2/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc-4.2/objdir/hppa -linux/libstdc++-v3/src -L/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/ src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/opt/gn u/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-l inux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include -g -O2 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc-4.2/objdir/h ppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gnu/gcc-4.2/objdir/hppa-l inux/libstdc++-v3/include -I/home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/libsupc++ -I /home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc-4. 2/gcc/libstdc++-v3/testsuite/util -Wl,--gc-sections /home/dave/gnu/gcc-4.2/gcc/l ibstdc++-v3/testsuite/22_locale/time_get/get_date/wchar_t/4.cc -include bits/ stdc++.h ./libtestc++.a -lm -o ./4.exe (timeout = 600) PASS: 22_locale/time_get/get_date/wchar_t/4.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc-4.2/objdir/gcc:/home/dave/gnu/gcc -4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc-4.2/objdir/g cc:/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs:/home/dave/ gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/.libs:/home/dave/gnu/gcc-4.2/objdir/h ppa-linux/libmudflap/.libs:/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libssp/.libs :/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libgomp/.libs:/home/dave/gnu/gcc-4.2/o bjdir/./gcc:/home/dave/gnu/gcc-4.2/objdir/./prev-gcc 4.exe: /home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/testsuite/22_locale/time_get/get_ date/wchar_t/4.cc:55: void test01(): Assertion `errorstate == ios_base::eofbit' failed. FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test extra_tool_flags are: -include bits/stdc++.h I'm only seeing this on one of my test systems. For a long time, I thought something was broken on it but finally I realized that this system is the only one that I have with the complete set of locales needed for the locale tests. The problem affects all active branches. locale -a ... zh_TW zh_TW.big5
I've tried all zh_TW locales available on debian etch and none work. With the default BIG5, time01 seems to contain garbage: (gdb) p time01 $2 = {tm_sec = 1, tm_min = 1, tm_hour = 0, tm_mday = 710656, tm_mon = 906548, tm_year = 1, tm_wday = 951080, tm_yday = 1078057400, tm_isdst = 0, tm_gmtoff = 64, tm_zone = 0x404001a3 ""}
Dave, unfortunately all the other linux targets are fine, therefore we have very big troubles figuring out what is happening on hppa only. Given that, as far as I know, no one among the v3 maintainers has access to hppa machines, I'm afraid that you have to do most of the investigation work here, despite the PR being categorized as libstdc++-v3... Just follow get_date... (remember to build the library -O0 -g3)
Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test > Dave, unfortunately all the other linux targets are fine, therefore we have > very big troubles figuring out what is happening on hppa only. Given that, as > far as I know, no one among the v3 maintainers has access to hppa machines, I'm > afraid that you have to do most of the investigation work here, despite the PR > being categorized as libstdc++-v3... Just follow get_date... (remember to build > the library -O0 -g3) Ok, I built the library with -O0 -g3 and stepped through trying to find the failure. It appears that the failure occurs here: std::ctype<wchar_t>::do_narrow (this=0x101f80, __wc=35199, __dfault=42 '*') at ctype_members.cc:221 221 do_narrow(wchar_t __wc, char __dfault) const Current language: auto; currently c++ (gdb) p/x __wc $20 = 0x897f (gdb) step 223 if (__wc >= 0 && __wc < 128 && _M_narrow_ok) (gdb) 226 __c_locale __old = __uselocale(_M_c_locale_ctype); (gdb) 228 const int __c = wctob(__wc); (gdb) 230 __uselocale(__old); (gdb) 232 return (__c == EOF ? __dfault : static_cast<char>(__c)); (gdb) p __c $22 = -1 The backtrace is: (gdb) bt #0 std::ctype<wchar_t>::do_narrow (this=0x101f80, __wc=35199, __dfault=42 '*') at ctype_members.cc:232 #1 0x00014a30 in std::__ctype_abstract_base<wchar_t>::narrow (this=0x101f80, __c=35199, __dfault=42 '*') at /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.h:327 #2 0x00035c94 in std::time_get<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::_M_extract_num (this=0x101f80, __beg= {<std::iterator<std::input_iterator_tag,wchar_t,long long int,wchar_t*,wchar_t&>> = {<No data fields>}, _M_sbuf = 0x101518, _M_c = 704643144}, __end= {<std::iterator<std::input_iterator_tag,wchar_t,long long int,wchar_t*,wchar_t&>> = {<No data fields>}, _M_sbuf = 0x897f, _M_c = 14}, __member=@0xe8748, __min=-1073172736, __max=0, __len=951080, __io=@0x101586, __err=@0x101580) at /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.tcc:2040 #3 0x00039194 in std::time_get<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::_M_extract_via_format (this=0x101f80, __beg= {<std::iterator<std::input_iterator_tag,wchar_t,long long int,wchar_t*,wchar_t&>> = {<No data fields>}, _M_sbuf = 0x101518, _M_c = 704643144}, __end= {<std::iterator<std::input_iterator_tag,wchar_t,long long int,wchar_t*,wchar_t&>> = {<No data fields>}, _M_sbuf = 0x897f, _M_c = 14}, __io=@0xe8748, __err=@0xc008af00, __tm=0x0, __format=0xe8328) at /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.tcc:1973 #4 0x000395d0 in std::time_get<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::do_get_date (this=0x101f80, __beg= {<std::iterator<std::input_iterator_tag,wchar_t,long long int,wchar_t*,wchar_t&>> = {<No data fields>}, _M_sbuf = 0x101518, _M_c = 704643144}, __end= {<std::iterator<std::input_iterator_tag,wchar_t,long long int,wchar_t*,wchar_t&>> = {<No data fields>}, _M_sbuf = 0x897f, _M_c = 14}, __io=@0xe8748, __err=@0xc008af00, __tm=0x0) at /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.tcc:2163 #5 0x000343cc in std::time_get<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::get_date (this=0x101f80, __beg= {<std::iterator<std::input_iterator_tag,wchar_t,long long int,wchar_t*,wchar_t&>> = {<No data fields>}, _M_sbuf = 0x101518, _M_c = 704643144}, __end= {<std::iterator<std::input_iterator_tag,wchar_t,long long int,wchar_t*,wchar_t&>> = {<No data fields>}, _M_sbuf = 0x897f, _M_c = 14}, __io=@0xe8748, __err=@0xc008af00, __tm=0x0) at /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale_facets.h:3147 #6 0x00010680 in test01 () at /home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/testsuite/22_locale/time_get/get_date/wchar_t/4.cc:54 #7 0x00010810 in main () at /home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/testsuite/22_locale/time_get/get_date/wchar_t/4.cc:63 The failure to narrow the character causes __err to get set here: /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale _facets.tcc:2055. This causes __tmperr to get set in 'Y' case. This causes __err to get set again here: /home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/bits/locale _facets.tcc:2017. This causes the VERIFY failure. Is the EOF result expected for the wctob call? Dave
Hi Dave. I tell you the first things I see on x86: do_get_date calls _M_extract_via_format. In the latter there is a loop over __i, from 0 to __len == 11: the char array __format is parsed. The first two times 'if (__ctype.narrow(__format[__i], 0) == '%')' is executed (that is, for i == 0, i == 1, where __format[0] == 0x897f (35199 base 10) and __format[1] == 0x5143), narrow returns -1 and we move ahead, that's expected, we are looking for a '%'. The third time a '%' is found, and then __c == 'Y'. I would suggest checking the contents of __format when _M_extract_via_format starts, that is verifying that it begins with the exact same two chars of wstr in the C++ source and therefore L'%' and L'Y'. Anyway, by the time we switch to 'Y', we moved ahead 2 positions in __format (__i == 2) and bumped two times __beg. Therefore _M_extract_num will start reading the third char of wstr, and then the other 3 forming a year L'2' L'0' L'0' L'3'... Note that in general, wctob can well return -1, every time there is no plain char equivalent of a multi byte char. In the testcase happens for the first two chars of __format, then finally we find L'%' and L'Y' which have of course '%' and 'Y' as equivalent.
(In reply to comment #4) > I would suggest checking the contents of __format when _M_extract_via_format > starts, that is verifying that it begins with the exact same two chars of wstr > in the C++ source and therefore L'%' and L'Y'. Sorry about the stupid typo: L'%' and L'Y' are of course the *third* and *fourth* char of __format. The first two are identical to the first two chars of wstr.
Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test > (In reply to comment #4) > > I would suggest checking the contents of __format when _M_extract_via_format > > starts, that is verifying that it begins with the exact same two chars of wstr > > in the C++ source and therefore L'%' and L'Y'. > > Sorry about the stupid typo: L'%' and L'Y' are of course the *third* and > *fourth* char of __format. The first two are identical to the first two chars > of wstr. I'm seeing L'%' and L'Y' as the first two characters in __format: (gdb) p __format[0] $34 = 37 (gdb) p __format[1] $35 = 89 Narrowing only occurs in just the one case that I mentioned (first character of wstr). Dave
(In reply to comment #6) > I'm seeing L'%' and L'Y' as the first two characters in __format: > (gdb) p __format[0] > $34 = 37 > (gdb) p __format[1] > $35 = 89 That means that something is going badly wrong when __dates[0] is set in do_get_date. You should follow __tp._M_date_formats(__dates), before the _M_extract_via_format call. And going back as much as necessary. Anyway, I would suggest you finding somewhere an x86, x86_64, ia64, powerpc or s390 system and have that as reference, ready at hand. Otherwise, the debugging will proceed too slowly.
One last remark: when something having to do with named locales doesn't work, often I find myself checking whether corresponding "C" code works. In this case, if __format is wrong, which means apparently that _M_data->_M_date_format is wrong, I suggest preparing a plain "C" snippet equivalent to the code in config/locale/gnu/time_members.cc which sets _M_data->_M_date_format, something like: loc = newlocale(1 << LC_ALL, __s, 0); union { char *__s; wchar_t *__w; } __u; __u.__s = __nl_langinfo_l(_NL_WD_FMT, loc); const wchar_t* pp = __u.__w; and inspect pp. Here it's fine.
Of course: const char* __s = "zh_TW";
Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test > ------- Comment #8 from pcarlini at suse dot de 2007-04-02 00:53 ------- > One last remark: when something having to do with named locales doesn't work, > often I find myself checking whether corresponding "C" code works. In this > case, if __format is wrong, which means apparently that _M_data->_M_date_format > is wrong, I suggest preparing a plain "C" snippet equivalent to the code in > config/locale/gnu/time_members.cc which sets _M_data->_M_date_format, something > like: > > loc = newlocale(1 << LC_ALL, __s, 0); > > union { char *__s; wchar_t *__w; } __u; > __u.__s = __nl_langinfo_l(_NL_WD_FMT, loc); > > const wchar_t* pp = __u.__w; Thanks for the tip. The following doesn't work on hppa but does on x86: #include <locale.h> #include <langinfo.h> #include <wchar.h> wchar_t * foo (void) { char *__s = "zh_TW"; wchar_t *pp; locale_t loc; union { char *__s; wchar_t *__w; } __u; loc = newlocale(1 << LC_ALL, __s, 0); __u.__s = nl_langinfo_l(_NL_WD_FMT, loc); pp = __u.__w; return pp; } int main () { wchar_t *pp; pp = foo (); return 0; } Displaying the return value from the call to foo yields (gdb) p ((wchar_t *)$ret0)[0] $1 = 37 So, I think the problem is in nl_langinfo_l. Dave
Ok, therefore we cannot consider anymore the issue a libstdc++ issue.
Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test > ------- Comment #11 from pcarlini at suse dot de 2007-04-02 10:32 ------- > Ok, therefore we cannot consider anymore the issue a libstdc++ issue. It's a generic issue wrt zh_TW and date representation. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352600 So, I would say this is a testsuite issue and the PR should be reopened. Dave
And you are volunteering to fix the testsuite issue, right? ;)
Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test > ------- Comment #13 from pcarlini at suse dot de 2007-04-22 17:50 ------- > And you are volunteering to fix the testsuite issue, right? ;) No, I know nothing about locales and I've got lot's of real PA bugs to investigate. I just got lucky finding the origin of this bug. Everything that affects x86 gets fixed, right? ;) I'm not aware of an easy way to check for Debian linux and its glibc version. So, the only fix that I can see is to check in the testcase for "<U897F><U5143>" and change wstr accordingly. Dave
(In reply to comment #14) > No, I know nothing about locales and I've got lot's of real PA bugs > to investigate. I just got lucky finding the origin of this bug. > Everything that affects x86 gets fixed, right? ;) Anything that affects any widespread target gets fixed.
(In reply to comment #14) > I'm not aware of an easy way to check for Debian linux and its glibc > version. So, the only fix that I can see is to check in the testcase > for "<U897F><U5143>" and change wstr accordingly. It would not be the first time Debian has some special weird issue, which nobody else see: just browse Bugzilla and you will find lots of those, closed as invalid. Thus, before taking any action which will affect anyone else, all the linux targets basically, I'd like to see some serious analysis explaining why Debian is right and all the other targets wrong.
I see the same issue on x86_64 debian linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg00085.html Removing hppa tags since it's debian-specific, not hppa.
Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test The bug still exists in gcc 4.3.1 on my amd 64 computer with 32 bit Linux(Debian Etch). During make check get error message. Should i be concerned? Is there any remedy for this problem? === libstdc++ tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/ad/dloads/gcc-4.3.1/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/ad/dloads/gcc-4.3.1/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... Running /home/ad/dloads/gcc-4.3.1/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) === libstdc++ Summary === # of expected passes 5570 # of unexpected failures 1 # of unexpected successes 1 # of expected failures 59 # of unsupported tests 10 make[4]: *** [check-DEJAGNU] Error 1 make[4]: Leaving directory `/home/ad/build_gcc/i686-pc-linux-gnu/libstdc++-v3/testsuite' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/ad/build_gcc/i686-pc-linux-gnu/libstdc++-v3/testsuite' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/ad/build_gcc/i686-pc-linux-gnu/libstdc++-v3' make[1]: *** [check-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/home/ad/build_gcc' make: *** [do-check] Error 2
Subject: Re: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test > The bug still exists in gcc 4.3.1 on my amd 64 computer with 32 bit > Linux(Debian Etch). During make check get error message. Should i be > concerned? Is there any remedy for this problem? No. The fail is the result of a political statement about Taiwanese dates by a Debian a maintainer. When I last checked into it, the change in the calendar had not been officially accepted. This was some months ago. The test should be xfailed on Debian. Dave
See debian bug 352600.
Sometime in Jan 2010 between revisions 155638 and 155826, this testcase stopped failing on the trunk: FAIL: http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg00507.html no FAIL: http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01034.html When I check the logfile, it now says: UNSUPPORTED: 22_locale/time_get/get_date/wchar_t/4.cc The testcase still fails on the 4.4/4.3 branches, so the "issue" on debian with locales still exists, but is masked on trunk because the testcase is not run. Was this intentional?
Kaveh, you are comparing apples to oranges: in the first case the GNU locale model is used, a complete set of locale data is installed, thus the testcase is run and it fails. In the second case, evidently one of the first two assumptions does not hold, thus the testcase is not run at all.
(In reply to comment #22) > Kaveh, you are comparing apples to oranges: in the first case the GNU locale > model is used, a complete set of locale data is installed, thus the testcase is > run and it fails. In the second case, evidently one of the first two > assumptions does not hold, thus the testcase is not run at all. The failure on the branches happens on the same box (CFARM gcc14). So the locale data is identical across these cases vs trunk. E.g.: 4.4: http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg00420.html 4.3: http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg00421.html
So you have to investigate why on your machine the GNU locale model is not used, the configury falls back to the generic model. Certainly nothing changed lately in this area, and, as you can see on testresults, people are definitely using the GNU locale model without any problem everywhere.
The test is disabled unless the machine actually has the relevant locale installed: // { dg-require-namedlocale "zh_TW.UTF-8" } That will be why some systems show UNSUPPORTED.
This still fails on any Debian system, such as gcc20 in the compile farm. I'd like to either make it pass, or add dg-xfail-if or dg-skip-if to the test. Paolo, do you remember if this testcase was specifically testing the zh_TW locale, or just sing that as an example of a locale using wide characters? Maybe we can change it to a different locale that still tests the same code, but using a locale that has consistent localedata across distros?
(In reply to Jonathan Wakely from comment #26) > Paolo, do you remember if this testcase was specifically testing the zh_TW > locale, or just sing that as an example of a locale using wide characters? s/just sing/just using/
Author: redi Date: Wed Aug 29 10:05:55 2018 New Revision: 263948 URL: https://gcc.gnu.org/viewcvs?rev=263948&root=gcc&view=rev Log: PR libstdc++/31413 fix test failure on Debian systems Debian uses a different D_FMT string for the zh_TW.UTF-8 locale, which caused this test to fail. Try to detect the Debian format and adjust the input being tested. PR libstdc++/31413 * testsuite/22_locale/time_get/get_date/wchar_t/4.cc: Check D_FMT string for alternative format. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/22_locale/time_get/get_date/wchar_t/4.cc
I've modified the test to also work with Debian's D_FMT string.