RFR(s): 8251930: AArch64: Native types mismatch in hotspot

[Andrew Haley]

On 18/08/2020 16:21, Anton Kozlov wrote:

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

Well, that's very silly. Out of interest, what is the fundamental
type? Or are they compiler builtins?

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

I wonder what ISO C++ says about all of this. We are in danger of
turning the code into an effectively unmaintainable mess because a
Linux programmer makes a change, it breaks Darwin, and vice versa.

Are there any compiler flags that might help here?

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

Maybe a template function for mov() ?

Be careful with sign extension. We want to make sure mov(reg, -1)
works correctly.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671