JDK-8253089 : Windows (MSVC 2017) build fails after JDK-8243208
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-09-14
  • Updated: 2024-11-22
  • Resolved: 2020-09-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 b16Fixed
Related Reports
Relates :  
Relates :  
Description
Tools summary:
* Environment:    cygwin version 3.1.7(0.340/5/3), 2020-08-22 17:48. Windows version 10.0.18363.1082. Root at /cygdrive/c/cygwin64
* Boot JDK:       openjdk version "14.0.1-internal" 2020-04-14  OpenJDK Runtime Environment (build 14.0.1-internal+0-adhoc..build)  OpenJDK 64-Bit Server VM (build 14.0.1-internal+0-adhoc..build, mixed mode, sharing)   (at /cygdrive/c/buildbot/jdks/jdk14)
* Toolchain:      microsoft (Microsoft Visual Studio 2017)
* C Compiler:     Version 19.16.27039 (at /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1416~1.270/bin/hostx86/x64/cl)
* C++ Compiler:   Version 19.16.27039 (at /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1416~1.270/bin/hostx86/x64/cl)

c:/buildbot/worker/build-jdkX-windows/build/src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): error C2220: warning treated as error - no 'object' file generated
c:/buildbot/worker/build-jdkX-windows/build/src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): warning C4307: '*': integral constant overflow
make[3]: *** [lib/CompileJvm.gmk:143: /cygdrive/c/buildbot/worker/build-jdkX-windows/build/build/windows-x86_64-server-fastdebug/hotspot/variant-server/libjvm/objs/jvmFlagLookup.obj] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [make/Main.gmk:259: hotspot-server-libs] Error 2
Comments
Changeset: 3f455f09 Author: Aleksey Shipilev <shade@openjdk.org> Date: 2020-09-15 05:14:06 +0000 URL: https://git.openjdk.java.net/jdk/commit/3f455f09
15-09-2020

u2 matches the underlying storage type in the final table and avoids a few casts along the way. It looks safe to me to calculate hash code directly in u2 domain. But sure, if you have better suggestion, do tell in GH review. (That would need another few hours to verify, as my Windows VMs are very slow).
14-09-2020

This may be an example of https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html This would explain why using u2 would dodge the warning. (Though I don't think that's an actually good solution.) The currently overflowing arithmetic operations would be on the promoted u2 values, so won't overflow.
14-09-2020

The change above did not work too. I am trying to use "u2" consistently now...
14-09-2020

Testing this: diff --git a/src/hotspot/share/runtime/flags/jvmFlagLookup.cpp b/src/hotspot/share/runtime/flags/jvmFlagLookup.cpp index 8f628987f56..75693df7fa9 100644 --- a/src/hotspot/share/runtime/flags/jvmFlagLookup.cpp +++ b/src/hotspot/share/runtime/flags/jvmFlagLookup.cpp @@ -39,7 +39,7 @@ constexpr JVMFlagLookup::JVMFlagLookup() : _buckets(), _table(), _hashes() { for (int i = 0; i < NUM_BUCKETS; i++) { - _buckets[i] = -1; + _buckets[i] = (short)-1; } ALL_FLAGS(DO_FLAG,
14-09-2020

Nope, that patch does not work. And I am not sure why it would work, since it relates to "h", which is already unsigned int. EDIT: Ah, that's constexpr, so any related code might fail, gaah.
14-09-2020

Maybe it's complaining about this "*" in jvmFlagLookup.hpp? How about this: static constexpr unsigned int hash_code(const char* s, size_t len) { unsigned int h = 0; while (len -- > 0) { - h = 31*h + (unsigned int) *s; + h = ((unsigned int)31)*h + (unsigned int) *s; s++; } return h;
14-09-2020

The error above is from MSVC 2017. MSVC 2019 seems to compile this code fine. MSVC bug then?
14-09-2020

Another try seems to work. In review now: https://github.com/openjdk/jdk/pull/150
14-09-2020