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

[Paolo Carlini <pcarlini at unitus dot it>]

Ulrich Weigand wrote:

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

Thanks for your feedback!

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

For the moment, let's concentrate on the first fail, which seems easier to me.

I'm not an UNICODE expert, but, indeed browsing the full test of the testcase, I fully agree with you that this is an endianness problem. Also:

1- B in UCS-2BE is for Big-endian, indeed, so this is the correct testcase for your machine.

2- For some reason, on s390 (and powerpc, which, I suppose, is big-endian too!) the library is behaving /as if/ the machine were little-endian!
Look below at the corresponding reference i_lit_base for little-endian machine: is exactly as yours i_arr.

Further thoughts?

Ciao, Paolo.