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 time being, let us concentrate on the first fail, which seems 
easier to deal with.
Indeed, I agree with you that this is an endianness problem. And, 
AFAICT, the BE in UCS-2BE is for Big Endian, therefore this is the right 
test to carry on s390.
However, for some reason, the library is behaving /as if/ the machine 
were little-endian! Compare the expected result i_lit with the expected 
result i_lit in test02 below (that for little-endian machine): the 
actual i_arr would perfectly match the latter!

Any further thoughts?

Thanks,
Paolo.

P.S. Sorry for my naiveté: powerpc is also big-endian, I suppose?