New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JDK-8295412 : support latest VS2022 MSC_VER in abstract_vm_version.cpp #10727
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine and trivial.
It is so annoying we need to do this. :(
@MBaesken This change now passes all automated pre-integration checks. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 12 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Hi David and Lutz, thanks for the reviews ! |
/integrate |
Going to push as commit bca7ab3.
Your commit was automatically rebased without conflicts. |
@dholmes-ora Why do you do this? If it needs to be done it should probably be extracted by the build system and sent into Hotspot as a define. But before I'd try to fix that, the first question is: do we really need this value? |
@magicus it is used to report the compiler version in hotspot internal version string (-Xinternalversion) in a clear way i.e.
versus
AFAIK MSC doesn't provide any exported means to map the build numbers back to a nice version string like this. |
Sorry, I was unclear. Yes, I know it is used for the version string. My question was more: I know this has traditionally been included in the version string, but is it really needed? What is the use case for having the compiler version? I can fully understand if this is included in a hs_err file, but in that case, maybe the simple "1933" value can suffice, and if the compiler version is suspected to be bad, we can look it up in a table. |
I assume it was desirable to have it hence it was added. I can't attest to the exact why. It was added by JDK-4286737 back in March 2000. |
Currently the latest VS2022 versions are not supported when checking _MSC_VER in abstract_vm_version.cpp, that should be improved.
See
https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
https://learn.microsoft.com/de-de/visualstudio/install/visual-studio-build-numbers-and-release-dates?view=vs-2022
Visual Studio 2022 version 17.3 1933
Visual Studio 2022 version 17.2 1932
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10727/head:pull/10727
$ git checkout pull/10727
Update a local copy of the PR:
$ git checkout pull/10727
$ git pull https://git.openjdk.org/jdk pull/10727/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 10727
View PR using the GUI difftool:
$ git pr show -t 10727
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10727.diff