localedata/sort-test on powerpc

[Adhemerval Zanella]

On 02/11/2021 13:34, Carlos O'Donell wrote:
> On 11/2/21 09:35, Adhemerval Zanella wrote:
>> Hi Carlos, 
>>
>> I am seeing a constant error on powerpc (32-bits) regarding C.UTF-8 support:
> 
> I only tested x86_64, i686, aarch64, s390x, and armv7hl, and saw no regressions.
> 
>> C.UTF-8 collate-test FAIL
>>   --- C.UTF-8.in        2021-09-29 14:38:38.520581614 +0300
>>   +++ /home/azanella/projects/glibc/build/powerpc-linux-gnu/localedata/C.UTF-8.out      2021-11-02 16:02:40.166588342 +0300
>>   @@ -1,3 +1,1221 @@
>>   +`󠀁' and `f' collate wrong: 1711277981 vs. -207585151
>>   +`󠀁' and ``' collate wrong: 1610614685 vs. -207585151
>>   [...]
> 
> This is a failure in the initial sanity check.
> 
> The initial sanity check is non-deterministic because we use srandom/random to shuffle the list.
> 
> The shuffle picks 2 entries and swaps them.
> 
> While we have 2 entries we check that strcoll is commutative.
> 
> The commutativity is *oddly* computed with a multiplication... that can now overflow?
> 
>  96       /* While we are at it a first little test.  */
>  97       r1 = strcoll (strings[idx1].key, strings[idx2].key);
>  98       r2 = strcoll (strings[idx2].key, strings[idx1].key);
>  99       r = r1 * r2;
> 100 
> 101       if (r > 0 || (r == 0 && r1 != 0) || (r == 0 && r2 != 0))
> 102         printf ("`%s' and `%s' collate wrong: %d vs. %d\n",
> 103                 strings[idx1].key, strings[idx2].key, r1, r2);
> 
> Line 99 was always wrong because int * int can result in an undefined
> signed integer overflow.

But does the overflow really matter here since what it checks the sign of
the multiplication, not the value? 

> 
> This should be rewritten.
> 
>> And I am not sure, but I think I started to see it after C.UTF-8 has landed.
>> I don't see it on other architectures, neither on another 32-bit BE (s390). 
>  
> Fix the check and see if that solves it?
>