On Wed, 9 Nov 2022 12:15:28 GMT, Magnus Ihse Bursie <[email protected]> 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
