[aarch64-port-dev ] RFR: 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode

[Dmitrij Pochepko]

Looks good.

Sorry for the trouble of fixing it.


Do you need help with push?


Thanks,

Dmitrij

On 10/12/2018 11:41 AM, Nick Gasson (Arm Technology China) wrote:
> Hi,
>
> Please help me review this patch to fix an intermittent failure of
> java/util/Calendar/Bug8167273.java on AArch64.
>
> Webrev: http://cr.openjdk.java.net/~njian/8215100/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8215100
> (also https://bugs.openjdk.java.net/browse/JDK-8209402)
>
> The calendar test failure reported in JDK-8209402 happens because it
> can't find a particular key in a TreeMap, but if you dump out the
> contents of that TreeMap, the key is present but the tree is not
> sorted correctly.
>
> It's caused by a bug in the compareTo intrinsic that's triggered when
> both arguments are four characters long but one is Latin1 encoded and
> one is Unicode encoded. In that case the "Compare longwords" loop
> header (isLU or else branches) will branch to the TAIL_CHECK label
> with tmp1 (isLU) or tmp2 (isUL) uninitialized. The instructions after
> TAIL_CHECK assume tmp1 and tmp2 contain the final 64-bit words of each
> string, and use these to compute the difference between the final
> characters. In the LU/UL case this result is garbage.
>
> Fix by handling four-character mixed U/L strings in the SHORT_STRING
> loop (currently this is done for length < 4). Also extended the
> existing string intrinsics test to catch this.
>
> Thanks,
> Nick