RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v4]

Kim Barrett kbarrett at openjdk.org
Tue Aug 26 13:34:38 UTC 2025


On Tue, 26 Aug 2025 12:44:33 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address.
>> To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. 
>> 
>> Tests:
>> mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product}
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   explicit casting of 'long long' vs 'long' for windows compatibility.

Changes requested by kbarrett (Reviewer).

test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 307:

> 305: 
> 306:   val = jlong_from(0xFFFFFFFF, 0);
> 307:   EXPECT_EQ(                    val, (signed long long)0xFFFFFFFF00000000);

Oops! Sorry I missed that these tests were previously casting to `long`
variants. Never use `long` in shared code. But we also almost never use `long
long` in shared code. (And a couple of the uses look a bit questionable. I'll
be following up on those.) Use CONST64 and UCONST64 to form the 64 bit
constants, rather than casts.

test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 308:

> 306:   val = jlong_from(0xFFFFFFFF, 0);
> 307:   EXPECT_EQ(                    val, (signed long long)0xFFFFFFFF00000000);
> 308:   EXPECT_EQ((unsigned long long)val,                   0xFFFFFFFF00000000);

I think this should be

EXPECT_EQ((julong)val, UCONST64(0xFFFFFFFF00000000));

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

PR Review: https://git.openjdk.org/jdk/pull/26809#pullrequestreview-3155654041
PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2301010601
PR Review Comment: https://git.openjdk.org/jdk/pull/26809#discussion_r2301011815


More information about the hotspot-dev mailing list