RFR: 8187676: Disable harmless uninitialized warnings for two files

[Vladimir Kozlov]

I would prefer to have general solution Rahul is working on because code 
is general - not only x86 is affected.

Thanks,
Vladimir

On 9/19/17 7:59 AM, Rahul Raghavan wrote:
> Hi Erik,
> 
> Please note that this 8187676 seems to be related to 8160404.
>     https://bugs.openjdk.java.net/browse/JDK-8160404
>     (RelocationHolder constructors have bugs)
> 
> As per the latest notes comments added for 8160404-jbs, I will submit 
> webrev/RFR soon and will request help confirm similar issues with latest 
> gcc7 gets solved.
> 
> Thanks,
> Rahul
> 
> On Tuesday 19 September 2017 07:07 PM, Erik Helin wrote:
>> Hi all,
>>
>> with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the 
>> potential usage of maybe uninitialized memory in 
>> src/hotspot/cpu/x86/assembler_x86.cpp and in 
>> src/hotspot/cpu/x86/interp_masm_x86.cpp.
>>
>> The problems arises from the class RelocationHolder in 
>> src/hotspot/share/code/relocInfo.hpp which has the private fields:
>>    enum { _relocbuf_size = 5 };
>>    void* _relocbuf[ _relocbuf_size ];
>>
>> and the default constructor for RelocationHolder does not initialize 
>> the elements of _relocbuf. I _think_ this is an optimization, 
>> RelocationHolder is used *a lot* and setting the elements of 
>> RelocationHolder::_relocbuf to NULL (or some other value) in the 
>> default constructor might result in a performance penalty. Have a look 
>> in 
>> build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles 
>> and you will see that RelocationHolder is used all over the place :)
>>
>> AFAICS all users of RelocationHolder::_relocbuf take care to not use 
>> uninitialized memory, which means that this warning is wrong, so I 
>> suggest we disable the warning -Wmaybe-uninitialized for 
>> src/hotspot/cpu/x86/assembler_x86.cpp.
>>
>> The problem continues because the class Address in 
>> src/hotspot/cpu/x86/assembler_x86.hpp has a private field, 
>> `RelocationHolder _rspec;` and the default constructor for Address 
>> does not initialize _rspec._relocbuf (most likely for performance 
>> reasons). The class Address also has a default copy constructor, which 
>> will copy all the elements of _rspec._relocbuf, which will result in a 
>> read of uninitialized memory. However, this is a benign usage of 
>> uninitialized memory, since we take no action based on the content of 
>> the uninitialized memory (it is just copied byte for byte).
>>
>> So, in this case too, I suggest we disable the warning -Wuninitialized 
>> for src/hotspot/cpu/x86/assembler_x86.hpp.
>>
>> What do you think?
>>
>> Patch:
>> http://cr.openjdk.java.net/~ehelin/8187676/00/
>>
>> --- old/make/hotspot/lib/JvmOverrideFiles.gmk    2017-09-19 
>> 15:11:45.036108983 +0200
>> +++ new/make/hotspot/lib/JvmOverrideFiles.gmk    2017-09-19 
>> 15:11:44.692107277 +0200
>> @@ -32,6 +32,8 @@
>>   ifeq ($(TOOLCHAIN_TYPE), gcc)
>>     BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := 
>> -fno-var-tracking-assignments -O0
>>     BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := 
>> -fno-var-tracking-assignments
>> +  BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized
>> +  BUILD_LIBJVM_interp_masm_x86.cpp_CXXFLAGS := -Wno-uninitialized
>>   endif
>>
>>   ifeq ($(OPENJDK_TARGET_OS), linux)
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8187676
>>
>> Testing:
>> - Compiles with:
>>    - gcc 7.1.1 and glibc 2.25 on Fedora 26
>>    - gcc 4.9.2 and glibc 2.12 on OEL 6.4
>> - JPRT
>>
>> Thanks,
>> Erik