Hi Thanks for background. Assuming these or similar issues were already discussed and it was decided to ignore warnings for code coverage builds I think it is fine to fix build. Current warnings don't look as real issues for me also.
I moved components alias as bcc since now it is build-only changes. The build is fixed to don't treat warnings as errors by default when code coverage is enabled. new webrev: http://cr.openjdk.java.net/~lmesnik/8209520/webrev.01/ <http://cr.openjdk.java.net/~lmesnik/8209520/webrev.01/> Leonid > On Aug 23, 2018, at 3:44 PM, Igor Ignatev <igor.ignat...@oracle.com> wrote: > > Hi Leonid, > > We have never supported native code coverage builds with warnings enabled as > errors. There are bugs in gcc which cause false positive warnings, so it was > decided to ignore all warnings from instrumented builds. It’d be much better > and reliable to fix makefiles to always use ‘disable-warning-as-errors’ when > ‘enable-native-coverage’ is used. It should be pretty straightforward to do. > > cc’ing build alias. > > Cheers, > — Igor > >> On Aug 23, 2018, at 2:37 PM, Vladimir Kozlov <vladimir.koz...@oracle.com> >> wrote: >> >> macroassembler changes are good. >> >> Thanks, >> Vladimir >> >>> On 8/23/18 1:51 PM, Leonid Mesnik wrote: >>> Hi >>> Could you please review following fix which fix code so gcc doesn't >>> complain when JDK is build with enabled native code coverage. >>> webrev: http://cr.openjdk.java.net/~lmesnik/8209520/webrev.00/ >>> <http://cr.openjdk.java.net/%7Elmesnik/8209520/webrev.00/> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8209520 >>> These warning appeared because of change optimization settings used for >>> getting code coverage. >>> 1) src/hotspot/cpu/x86/macroAssembler_x86.cpp, >>> src/hotspot/share/gc/shared/genCollectedHeap.cpp >>> gcc complained about uninitialized variables, like >>> * For target hotspot_variant-server_libjvm_objs_macroAssembler_x86.o: >>> /home/lmesnik/ws/jdk-8209520/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp: >>> In member function 'void ControlWord::print() const': >>> /home/lmesnik/ws/jdk-8209520/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:5769:11: >>> error: 'pc' may be used uninitialized in this function >>> [-Werror=maybe-uninitialized] >>> printf("%04x masks = %s, %s, %s", _value & 0xFFFF, f, rc, pc); >>> ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> /home/lmesnik/ws/jdk-8209520/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:5769:11: >>> error: 'rc' may be used uninitialized in this function >>> [-Werror=maybe-uninitialized] >>> So I just fixed codepath to show more explicitly that variables are >>> initialized before usage. >>> 2) src/java.desktop/share/native/libsplashscreen/splashscreen_png.c: >>> The changes to prevent waning about clobbering in splashscreen_png.c are >>> similar to fix in: >>> 1. JDK-8080695 <https://bugs.openjdk.java.net/browse/JDK-8080695> >>> splashscreen_png.c compile error with gcc 4.9.2 >>> The another approach would be to fix build to ignore these warnings for >>> code coverage build. While I think it makes build system even more >>> complicated. >>> Leonid >
