JTreg test java/util/Calendar/Bug8167273.java fails on
AArch64. This test checks the consistency of the era names (e.g. AD/BC)
between each locale in two different databases of locale information. It
fails on AArch64 for the az_AZ_#Latn locale, but only when using tiered
compilation (i.e. it passes with -Xcomp or -Xint).

It fails 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. The root problem is String::compareTo returns a
different value when running in the interpreter and when compiled (the
compiled result is wrong).

Here is a much simpler test that shows the problem:

  public class CompareTo {
    public static void main(String args[]) {
      final String[] strings = { "e.\u0259.", "y.e." };
      strings[0].compareTo(strings[1]);
      for (String s1 : strings) {
        for (String s2 : strings) {
          System.out.println(s1.compareTo(s2));
        }
      }
    }
  }

With -Xint you get the correct result "0 -20 20 0" but -Xcomp gives "0
-707 20 0". 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.

This was broken sometime between JDK 10 and 11.