This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC/H] Testsuite fails: powerpc/s390-linux-gnu and alpha-linux-gnu


Paolo Carlini wrote:

>now the that the testsuite looks nice for i686 and ia64 linux-gnu, it would be
>nice to begin seriously tackling the remaining problems on at least other
>linux-gnu platforms. To wit:
>
>Two /unexpected/ on both powerpc and s390-linux-gnu:
>----------------------------------------------------
>22_locale/codecvt_members_unicode_char.cc execution test
>22_locale/codecvt_members_unicode_wchar_t.cc execution test


I haven't looked in detail into these problems, but these are the
result I got on a first glance.

The first test case fails with:

codecvt_members_unicode_char.exe: /mnt/dasdb1/weigand/fsf/gcc-3_1/libstdc++-v3/testsuite/22_locale/codecvt_members_unicode_char.cc:103:
void test01(): Assertion `!int_traits::compare(i_arr, i_lit, size)' failed.
Aborted (core dumped)

97        unicode_codecvt::state_type state01("UCS-2BE", "ISO-8859-15", 0xfeff, 0);
98        initialize_state(state01);
99        // internal encoding is bigger because of bom
100       result r1 = cvt.in(state01, e_lit, e_lit + size, efrom_next,
101                          i_arr, i_arr + size + 1, ito_next);
102       VERIFY( r1 == codecvt_base::ok );
103       VERIFY( !int_traits::compare(i_arr, i_lit, size) );
104       VERIFY( efrom_next == e_lit + size );
105       VERIFY( ito_next == i_arr + size );

At this time, the two arrays that are supposed to be equal contain:

(gdb) x/32xh i_lit
0x7ffff738:     0x6200  0x6c00  0x6100  0x6300  0x6b00  0x2000  0x7000  0x6500
0x7ffff748:     0x6100  0x7200  0x6c00  0x2000  0x6a00  0x6100  0x7300  0x6d00
0x7ffff758:     0x6900  0x6e00  0x6500  0x2000  0x7400  0x6500  0x6100  0xa000
0x7ffff768:     0x0000  0x0000  0x0000  0x0000  0x7fff  0xf738  0x004b  0x3801
(gdb) x/32xh i_arr
0x4e8c18:       0x0062  0x006c  0x0061  0x0063  0x006b  0x0020  0x0070  0x0065
0x4e8c28:       0x0061  0x0072  0x006c  0x0020  0x006a  0x0061  0x0073  0x006d
0x4e8c38:       0x0069  0x006e  0x0065  0x0020  0x0074  0x0065  0x0061  0x0000
0x4e8c48:       0x0000  0x0000  0x0000  0x0289  0x0000  0x0001  0x0000  0x0001

This does look like an endianness problem, but I'm not sure (what is the
relationship between UCS-2BE/UCS-2LE and the endianness of the platform?).
S/390 is a big-endian machine.

The second test fails with:

codecvt_members_unicode_wchar_t.exe: /mnt/dasdb1/weigand/fsf/gcc-3_1/libstdc++-v3/testsuite/22_locale/codecvt_members_unicode_wchar_t.cc:83:
void test01(): Assertion `r1 == codecvt_base::ok' failed.
Aborted (core dumped)

79        unicode_codecvt::state_type state01("UCS-2BE", "UCS4", 0xfeff, 0);
80        initialize_state(state01);
81        result r1 = cvt.in(state01, e_lit, e_lit + size, efrom_next,
82                           i_arr, i_arr + size + 1, ito_next);
83        VERIFY( r1 == codecvt_base::ok );
84        VERIFY( !int_traits::compare(i_arr, i_lit, size) );
85        VERIFY( efrom_next == e_lit + size );
86        VERIFY( ito_next == i_arr + size );

(gdb) print r1
$1 = error

(gdb) x/32xh e_lit
0x7ffff6c8:     0x6200  0x0000  0x6c00  0x0000  0x6100  0x0000  0x6300  0x0000
0x7ffff6d8:     0x6b00  0x0000  0x2000  0x0000  0x7000  0x0000  0x6500  0x0000
0x7ffff6e8:     0x6100  0x0000  0x7200  0x0000  0x6c00  0x0000  0x2000  0x0000
0x7ffff6f8:     0x6a00  0x0000  0x6100  0x0000  0x7300  0x0000  0x6d00  0x0000
(gdb) x/32xh i_arr
0x4e8498:       0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x4e84a8:       0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x4e84b8:       0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000  0x0000
0x4e84c8:       0x0000  0x0000  0x0000  0x0289  0x0000  0x0001  0x0000  0x0001

Again, this might be an endianness problem ...


Both tests are running against a 2.2.5 glibc.   Does this give you some
ideas what the problem might be?  Otherwise I'll have to dig deeper.

Thanks for looking into this!


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]