RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang

[Kim Barrett]

On Sat, 29 Jan 2022 14:44:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 136:
>> 
>>> 134:   if (nbits == 64) {
>>> 135:     assert(count <= 1, "must be");
>>> 136:     return bits;
>> 
>> For consistency with the < 64 case, shouldn't this be `return (count == 0) ? 0 : bits;` ?
>
> @kimbarrett - Thanks for the review! Good catch! I believe you are correct,
> but let's wait for @adinn to chime in here.

Returning 0 if count == 0 and bits otherwise is consistent with the old code,
assuming the problematic shift doesn't cause UB data corruption or something
otherwise strange.  It might do the "mathematically correct" thing of shifting
out all the bits (so zeroing the value).  Another possibility is that the
implemented shift amount for N is N mod word-size (some platforms do that, but
I haven't looked up aarch64), which in this case is 64 mod 64, or 0.  I don't
think there are any other non-strange non-UB-data-corruption possibilities.


result is initially 0.
with the old code:
- if count == 0, there are no iterations, and final result is still 0.
- if count == 1, there is one iteration.
  result <<= nbits
    -- if UB corruption, all bets are off
    -- if shifts by 64, result is unchanged (== 0)
    -- if shifts by 64 mod 64 (== 0), result is unchanged (== 0)
  result |= (bits & mask)
    -- result == bits
- if count > 1, for additional iterations
  result <<= nbits
    -- if UB corruption, all bets are off
    -- if shifts by 64, result == 0
    -- if shifts by 64 mod 64 (== 0), result is unchanged (== bits)
  result |= (bits & mask)
    -- result == bits

So with old code, for count > 0, result == bits (or UB corrupted data).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7270