[aarch64-port-dev ] RFR[XXS] 8248672: utilities: Introduce DEPRECATED macro for GCC and MSVC

[Ludovic Henry]

Hi,

I confirm that `= delete` works, and that we get a compile-time error if you try to use it.

Please find the updated webrev at http://cr.openjdk.java.net/~burban/luhenry/8248672/webrev.01

Thank you
Ludovic

________________________________________
From: Ludovic Henry <luhenry at microsoft.com>
Sent: Sunday, July 26, 2020 16:10
To: Kim Barrett; Andrew Haley
Cc: Vladimir Kozlov; hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64; hotspot-gc-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR[XXS] 8248672: utilities: Introduce DEPRECATED macro for GCC and MSVC

> As of early last week, a definition of "= delete;" is the way to
> poison an overload.

Let me try that locally, compile on Windows-AArch64 and Linux-AArch64, and confirm whether it works for MSVC.

________________________________________
From: Kim Barrett <kim.barrett at oracle.com>
Sent: Sunday, July 26, 2020 14:41
To: Andrew Haley
Cc: Ludovic Henry; Vladimir Kozlov; hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64; hotspot-gc-dev at openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR[XXS] 8248672: utilities: Introduce DEPRECATED macro for GCC and MSVC

> On Jul 26, 2020, at 5:56 AM, Andrew Haley <aph at redhat.com> wrote:
>
> On 25/07/2020 00:42, Kim Barrett wrote:
>> Why are we deprecating something rather than just deleting it and
>> fixing any users?
>
> C++ overloading. AArch64 CMP (immediate) only has a limited range, so
> we only have a byte-wide Assembler::cmp() definition. The deprecation
> warning on the wider version makes sure that any maintenance
> programmer is immediately warned if it is used. There are other things
> we could do: by not providing a definition for the wider cmp() you get
> a link error, but that wouldn't be as explicit as a deprecation
> warning.
>
> The root problem is that the immediate value to CMP isn't always known
> when HotSpot is compiled, but may be calculated at runtime. We have
> seen failures in production when an immediate offset overflowed.

Yeah, I'd guessed that might be the point, and confirmed it later by
looking at the changeset that originally introduced the attribute.

As of early last week, a definition of "= delete;" is the way to
poison an overload.