[Bug libstdc++/31413] New: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[Bug libstdc++/31413] New: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[danglin at gcc dot gnu dot org]

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


-- 
           Summary: FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution
                    test
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[danglin at gcc dot gnu dot org]

------- Comment #1 from danglin at gcc dot gnu dot org  2007-03-31 19:49 -------
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 ""}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- Comment #2 from pcarlini at suse dot de  2007-03-31 20:38 -------
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)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2007-04-01 21:36 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- Comment #4 from pcarlini at suse dot de  2007-04-01 23:23 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- Comment #5 from pcarlini at suse dot de  2007-04-01 23:34 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2007-04-02 00:16 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- Comment #7 from pcarlini at suse dot de  2007-04-02 00:31 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- 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;

and inspect pp. Here it's fine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- Comment #9 from pcarlini at suse dot de  2007-04-02 00:54 -------
Of course:

  const char* __s = "zh_TW";


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2007-04-02 03:36 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- Comment #11 from pcarlini at suse dot de  2007-04-02 10:32 -------
Ok, therefore we cannot consider anymore the issue a libstdc++ issue.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca  2007-04-22 17:47 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- Comment #13 from pcarlini at suse dot de  2007-04-22 17:50 -------
And you are volunteering to fix the testsuite issue, right? ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca  2007-04-22 18:17 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- Comment #15 from pcarlini at suse dot de  2007-04-22 18:20 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[pcarlini at suse dot de]

------- Comment #16 from pcarlini at suse dot de  2007-04-22 18:24 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[ghazi at gcc dot gnu dot org]

------- Comment #17 from ghazi at gcc dot gnu dot org  2008-04-02 14:18 -------
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.


-- 

ghazi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ghazi at gcc dot gnu dot org
  GCC build triplet|hppa-unknown-linux-gnu      |
   GCC host triplet|hppa-unknown-linux-gnu      |
 GCC target triplet|hppa-unknown-linux-gnu      |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[dtom77 at gmail dot com]

------- Comment #18 from dtom77 at gmail dot com  2008-06-28 02:55 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca  2008-06-28 03:47 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[danglin at gcc dot gnu dot org]

------- Comment #20 from danglin at gcc dot gnu dot org  2008-06-28 03:55 -------
See debian bug 352600.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[ghazi at gcc dot gnu dot org]

------- Comment #21 from ghazi at gcc dot gnu dot org  2010-02-05 16:55 -------
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #22 from paolo dot carlini at oracle dot com  2010-02-05 17:04 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[ghazi at gcc dot gnu dot org]

------- Comment #23 from ghazi at gcc dot gnu dot org  2010-02-05 17:26 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413

[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

[paolo dot carlini at oracle dot com]

------- Comment #24 from paolo dot carlini at oracle dot com  2010-02-05 17:30 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413