localedata/sort-test on powerpc

localedata/sort-test on powerpc

[Adhemerval Zanella]

Hi Carlos, 

I am seeing a constant error on powerpc (32-bits) regarding C.UTF-8 support:

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

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

Re: localedata/sort-test on powerpc

[Carlos O'Donell]

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.

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?

-- 
Cheers,
Carlos.

Re: 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?
> 

Re: localedata/sort-test on powerpc

[Andreas Schwab]

On Nov 02 2021, Adhemerval Zanella via Libc-alpha wrote:

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

There is no requirement that an overflowing multiplication results in
any useful value.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."