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

Kim Barrett kim.barrett at oracle.com
Sun Jul 26 21:41:47 UTC 2020

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

More information about the hotspot-gc-dev mailing list