RFR: 8294314: Minimize disabled warnings in hotspot [v4]

[Kim Barrett]

On Tue, 27 Sep 2022 14:44:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/hotspot/lib/CompileJvm.gmk line 95:
>> 
>>> 93: 
>>> 94: DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \
>>> 95:     missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas
>> 
>> Per JDK-9240259, -Wshift-negative-value should remain globally disabled, for
>> all of gcc and clang (and xlc, where it hasn't been removed).
>> 
>> Per discussion for JDK-8211073, -Wempty-body should remain globally disabled
>> for gcc.
>> 
>> As for the other gcc and clang warnings being removed from the globally
>> disabled lists, that looks okay to me. I'm particularly happy to see
>> -Wstrict-overflow removed from that list, and that we don't seem to have any
>> of those any more.
>> 
>> I've not looked at the changes to warnings for Windows.
>
> You mentioned shift-negative-value earlier in this PR. I apologize I forgot about it.
> 
> I can't find any discussion about JDK-8211073 wrt to `-Wempty-body` (are you sure this is the correct bug ID?), but I can put that as well to the globally disabled set.
> 
> As for xlc, I have no access to that compiler and I have therefore not done much changes here. But I think xlc compiles with "warnings as errors" off by default so most likely the people still supporting the AIX port don't care that much about warnings.

JDK-8211073 is the correct bug id. 

JDK-8211073 Remove -Wno-extra from Hotspot

There were two attempts at addressing this, about a year apart.
The first one can be found here:
https://mail.openjdk.org/pipermail/hotspot-dev/2018-September/034314.html
and continuing here:
https://mail.openjdk.org/pipermail/hotspot-dev/2018-October/034496.html
with the explanation for disabling `-Wempty-body` here:
https://mail.openjdk.org/pipermail/hotspot-dev/2018-October/034526.html

The second, successful, attempt at it is here:
https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039808.html

Leaving xlc to the relevant port maintainers seems like a wise choice.

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

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