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

[Bernhard Urban-Forster]

Hi Anton,

> Another approach is to leave a single overload for integer type, but literal
integer could still be ambiguously promoted to e.g. pointer or int64. So every user will have to explicitly cast literal integers to a certain type.

That's how I did it initially, but it's quite a noisy patch and in reality doesn't add any value, so I prefer your solution.

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.

Otherwise your change looks good (but I'm not a reviewer :-)).


Thanks,
-Bernhard


[1] https://bugs.openjdk.java.net/browse/JDK-8248414

________________________________________
From: aarch64-port-dev <aarch64-port-dev-retn at openjdk.java.net> on behalf of Anton Kozlov <akozlov at azul.com>
Sent: Tuesday, August 18, 2020 17:21
To: hotspot-dev at openjdk.java.net
Cc: aarch64-port-dev at openjdk.java.net
Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot

Hi,

Could you please review a fix for C++ types mismatch in cpu/aarch64.

Bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8251930&data=02%7C01%7Cbeurba%40microsoft.com%7Cd014403573904a86151008d8438956d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333604431135902&sdata=jgh%2FFoiw2n80g54p%2B8WyrODMswn9Hst0gt3eVnn2%2B%2BY%3D&reserved=0
Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~akozlov%2F8251930%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7Cd014403573904a86151008d8438956d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333604431135902&sdata=IKEdHXv0rIK4DqVqDfI%2BN2o7ArwctDiltSRi8vmvP0Y%3D&reserved=0

The issue was discovered by trying to compile by aarch64-darwin toolchain, but
it just uncovered a more general problem.

Extra method overloads with for int, long, ... are added to catch all (suitable)
types used for intptr_t, int64_t. Now there are overloads only for int (for
literal values) and int64, latter usually shares a fundamental type with intptr.
The new toolchain provides different types for int64 and intptr. Then both
overloads are not perfect for an intptr argument but possible, so compilation is
failed.  Providing additional overload for intptr fixes compilation on new
toolchain but breaks linux, as intptr and int64 are different overloads for
essentially the same type.
Another approach is to leave a single overload for integer type, but literal
integer could still be ambiguously promoted to e.g. pointer or int64. So every
user will have to explicitly cast literal integers to a certain type.

Tested on aarch64-darwin (succesfully compiles cpu/aarch64 code) and
aarch64-linux toolchains.

Thanks,
Anton