RFR: 8296115: Allow for compiling the JDK with strict standards conformance [v4]

[Julian Waters]

On Wed, 9 Nov 2022 12:15:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> FWIW, `-permissive-` is getting less permissive with every compiler iteration; with MSVC2022 (` C Compiler:     Version 19.33.31629`) even hotspot doesn't build.
>
> @djelinski That's a bit alarming. :-/ Do you have any idea if it complains "correctly" on Hotspot by detecting fishy code that should be fixed, or if it is overly cranky and is complaining about reasonable but non-standard extensions?

> @magicus that depends on how you define "cranky"; in default mode, `long` and `int` are fully interchangeable. In `permissive-`, they are [distinct types](https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#overload-resolution-involving-integral-overloads-and-long-arguments). As a result, compilation of code that assumes that `jint` is equal to `int` breaks (on Windows, `jint` is typedef'd to `long`).
> 
> Example failure:
> 
> ```
> C:...\src\hotspot\share\opto\mulnode.cpp(248): error C2668: 'uabs': ambiguous call to overloaded function
> C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1146): note: could be 'unsigned int uabs(int)'
> C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1145): note: or       'julong uabs(jlong)'
> C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1136): note: or       'julong uabs(julong)'
> C:...\src\hotspot\share\utilities/globalDefinitions.hpp(1127): note: or       'unsigned int uabs(unsigned int)'
> C:...\src\hotspot\share\opto\mulnode.cpp(248): note: while trying to match the argument list '(const jint)'
> ```
> 
> FWIW, clang-cl also fails on this.

I recall having had to deal with this while trying to wrestle the Windows JDK into being accepted by gcc, the solution was to simply define jint to int instead as it is with the Unix JDK (there were also sizeof checks to typedef jlong to either long or long long, but that's another story). From what I recall back when this was an issue for me this actually worked very well, the only time it choked up was when a jint was compared with a long, which is surprisingly only in rather few sections of native code. The inverse however, trying to make the JDK go with jint being typedef'd as long, is significantly harder

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

PR: https://git.openjdk.org/jdk/pull/10912