<AWT Dev> 8209520: Build fails when native code coverage is enabled

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Thu Aug 30 09:22:26 UTC 2018

On 2018-08-24 00:44, Igor Ignatev 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.
I disagree.

While it is simple to change the build to disable warnings as error when 
building with code coverage, I think hard-coding this into the build 
system is a step backwards :-( and not something I want to support.

The code changes suggested by Leonid seems trivial and benign, and helps 
readability, even apart from fixing compiler warnings.

If this is deemed unacceptable, it's better to disable those few 
warnings specifically, for the files/libraries they occur in.


> cc’ing build alias.
> Cheers,
> — Igor
>> On Aug 23, 2018, at 2:37 PM, Vladimir Kozlov <vladimir.kozlov at 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

More information about the awt-dev mailing list