RFR: 5038439: Warning message for literal shift amounts outside the canonical domain
    Archie Cobbs 
    acobbs at openjdk.org
       
    Tue Oct  7 19:40:35 UTC 2025
    
    
  
When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored.
This can create a trap for the unwary, as in this example:
public long readLongBigEndian(byte[] buf, int offset) {
    return ((buf[offset + 0] & 0xff) << 56)   // BUG HERE
         | ((buf[offset + 1] & 0xff) << 48)   // BUG HERE
         | ((buf[offset + 2] & 0xff) << 40)   // BUG HERE
         | ((buf[offset + 3] & 0xff) << 32)   // BUG HERE
         | ((buf[offset + 4] & 0xff) << 24)
         | ((buf[offset + 5] & 0xff) << 16)
         | ((buf[offset + 6] & 0xff) << 8)
         | ((buf[offset + 7] & 0xff);
}
This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`.
-------------
Commit messages:
 - Merge branch 'master' into JDK-5038439 to fix conflict.
 - Add "long" as a supported message parameter type.
 - Use "bit(s)" instead of "bits" where value could be 1.
 - Merge branch 'master' into JDK-5038439
 - Sprinkle more variety into the regression test.
 - Minor diff cleanup.
 - Update "lossy-conversions" description in compiler module Javadoc.
 - Warn for bit shifts using an out-of-range shift amount.
Changes: https://git.openjdk.org/jdk/pull/27102/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-5038439
  Stats: 194 lines in 14 files changed: 184 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27102.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27102/head:pull/27102
PR: https://git.openjdk.org/jdk/pull/27102
    
    
More information about the hotspot-compiler-dev
mailing list