On Mon, 26 Sep 2022 15:39:28 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now >> possible to disable warnings for individual files instead for whole >> libraries. I used this opportunity to go through all disabled warnings in >> hotspot. >> >> Any warnings that were only triggered in a few files were removed from >> hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for >> gcc, clang and visual studio. The remaining warnings are sorted in >> "frequency", that is, the first listed warnings are triggered in the most >> number of files, while the last in the fewest number of files. So if anyone >> were to try to address the remaining warnings, it would make sense to chop >> of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely >> be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. >> (But I have not yet gotten a fully green run due to instabilities in GHA, >> however this patch can't reasonably have anything to do with that.) As >> always, warnings tend to differ a bit between compilers, so if someone wants >> to take this on a spin with some other version, please go ahead. If I missed >> some warning, in worst case we'll just have to add it back again, and in the >> meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings >> in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to >> $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers >> `tautological-constant-out-of-range-compare` on clang, so while this is a >> single problem in a single file, this erupts all over the place in debug >> builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += >> tautological-constant-out-of-range-compare` for non-release builds can be >> removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Trigger GHA to compile with all warnings before aborting I ran all {x86_32, x86_64, aarch64, arm, powerpc64le, arm, riscv64} x {server} x {release,fastdebug} with GCC 10, and these are the new additions: diff --git a/make/common/MakeBase.gmk b/make/common/MakeBase.gmk index fa1d44396df..915b175a649 100644 --- a/make/common/MakeBase.gmk +++ b/make/common/MakeBase.gmk @@ -195,7 +195,7 @@ $(eval $(call SetupLogging)) ################################################################################ -MAX_PARAMS := 64 +MAX_PARAMS := 96 PARAM_SEQUENCE := $(call sequence, 2, $(MAX_PARAMS)) # Template for creating a macro taking named parameters. To use it, assign the diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk index ca38551c67d..7c37d5e2929 100644 --- a/make/hotspot/lib/CompileJvm.gmk +++ b/make/hotspot/lib/CompileJvm.gmk @@ -85,7 +85,7 @@ CFLAGS_VM_VERSION := \ DISABLED_WARNINGS_gcc := ignored-qualifiers comment int-in-bool-context \ array-bounds implicit-fallthrough parentheses missing-field-initializers \ - delete-non-virtual-dtor unknown-pragmas maybe-uninitialized + delete-non-virtual-dtor unknown-pragmas maybe-uninitialized shift-negative-value DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \ missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas @@ -162,9 +162,16 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBJVM, \ DISABLED_WARNINGS_gcc_loopnode.cpp := sequence-point, \ DISABLED_WARNINGS_gcc_macroArrayCopy.cpp := shift-negative-value, \ DISABLED_WARNINGS_gcc_mulnode.cpp := shift-negative-value, \ + DISABLED_WARNINGS_gcc_ad_ppc.cpp := empty-body, \ DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ DISABLED_WARNINGS_gcc_sharedRuntimeTrig.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_aarch64.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_ppc.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_riscv.cpp := misleading-indentation, \ DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_x86.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_aarch64.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_ppc.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_riscv.cpp := misleading-indentation, \ DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_x86.cpp := misleading-indentation, \ DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1.cpp := misleading-indentation, \ DISABLED_WARNINGS_gcc_signals_posix.cpp := cast-function-type, \ Unfortunately, in s390x case, the warning is in `assembler_s390.hpp`, which means a lot of compilation units fail. Therefore I introduced `shift-negative-value` back. I did not remove the per-file `shift-negative-value`-s, though. I shall deal with `misleading-indentation` the coding that produces these warnings some time later, maybe even ahead of this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10414
