[aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot

[Bernhard Urban-Forster]

Argh, I only tried my suggestion on aarch64-darwin, but you are right, it causes issues on aarch64-linux and presumably on aarch64-win as well.

Thanks for the explanation,
-Bernhard

________________________________________
From: Anton Kozlov <akozlov at azul.com>
Sent: Wednesday, August 19, 2020 10:55
To: Bernhard Urban-Forster; hotspot-dev at openjdk.java.net
Cc: aarch64-port-dev at openjdk.java.net; openjdk-aarch64
Subject: Re: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot

Hi Bernhard,

On 18.08.2020 22:43, Bernhard Urban-Forster wrote:
> I applied your patch on my WIP branch for aarch64-darwin and it builds for me as well. Just a small comment: With JDK-8248414 [1] we tried to eliminate many unsigned long/long usages, since "unsigned long" ends up with different bittness on LLP64 (Windows) vs. LP64 (Linux, macOS, etc.). So I would suggest to add overloads using the [u]int{32,64}_t + [u]intptr_t types instead, which adds a bit more clarity imho.

I also would like to have explicit overloads for int32_t/64_t/intptr_t, but as
I wrote it creates another issue. Consider a valid set of system types for LP64
(I think there are valid sets for LLP64 demonstrating the same):

  typedef int int32_t;
  typedef long int int64_t;
  typedef long int intptr_t;

then

  mov(Register, int64_t)  { /* overload 1 */ }
  mov(Register, intptr_t) { /* overload 2 */ }

are multiple overloads for same the same set of arguments, so it won't compile.

I don't like introducing fundamental types again too. But the patch treats
both (long) and (long long) uniformly, so the code should work for LLP64 as
well as for LP64.

It was really surprising for me, how smooth the work went and why hadn't you
solved the same problems in the latest JEP 388 patch, until I found 8248414 :-)
These bugs are linked in JBS.

Thanks,
Anton