RFR: 8187676: Disable harmless uninitialized warnings for two files

[Erik Helin]

Ok, lets wait for Rahul's patches. Rahul, when you post your patches, CC 
me and I can check if gcc 7.1.1 still complains :)

Thanks,
Erik

On 09/19/2017 06:25 PM, Vladimir Kozlov wrote:
> 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