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