RFR (s) 8141570: Fix Zero interpreter build for --disable-precompiled-headers

[David Holmes]

On 17/11/2015 12:47 PM, Coleen Phillimore wrote:
>
>
> On 11/16/15 9:11 PM, David Holmes wrote:
>> Hi Coleen,
>>
>> On 17/11/2015 11:36 AM, Coleen Phillimore wrote:
>>>
>>> Sorry that was the wrong webrev:
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8141570
>>
>> I may be missing something but in:
>>
>> make/linux/makefiles/zeroshark.make
>>
>> isn't the whole point of the original:
>>
>> ! # override this from the main file because some version of llvm do
>> not like -Wundef
>> ! WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wunused-function
>> -Wunused-value
>>
>> to avoid using the value set in gcc.make:
>>
>> WARNING_FLAGS = -Wpointer-arith -Wsign-compare -Wundef
>> -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type
>> -Woverloaded-virtual
>>
>> because the latter included -Wundef. Your new code simply adds new
>> warnings to the existing value of WARNING_FLAGS
>
> I don't think the code wants to ignore the warning flags passed in from
> gcc.make.  I think -Wformat=2 was the one that caused my build to fail
> (or maybe others).   For zero we just want to add more warning flags or
> disable them after the gcc flags.   Kim might be able to provide more
> detail because he found this.  In general I don't see why Zero would
> ever want to ignore the warnings we enable/disable for the rest of the jvm.

Presumably the -Wundef not working on some llvm is the reason :) And 
your changes now ensure -Wundef is set always.

David


> Coleen
>
>
>>
>> David
>> -----
>>
>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>>>>
>>>> After much discussion between Kim and I, I have a new change which
>>>> doesn't include .inline.hpp into a .hpp file.  This also fixes the
>>>> Zero build on my Ubuntu system.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>>>>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>>>>> fix
>>>>>>> the --disable-precompiled-headers Zero build for me:
>>>>>>>
>>>>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>>>>> b/src/share/vm/runtime/java.cpp
>>>>>>> --- a/src/share/vm/runtime/java.cpp
>>>>>>> +++ b/src/share/vm/runtime/java.cpp
>>>>>>> @@ -49,6 +49,7 @@
>>>>>>>    #include "runtime/arguments.hpp"
>>>>>>>    #include "runtime/biasedLocking.hpp"
>>>>>>>    #include "runtime/compilationPolicy.hpp"
>>>>>>> +#include "runtime/deoptimization.hpp"
>>>>>>>    #include "runtime/fprofiler.hpp"
>>>>>>>    #include "runtime/init.hpp"
>>>>>>>    #include "runtime/interfaceSupport.hpp"
>>>>>>>
>>>>>>> It does not seem the other change is required. Tested with
>>>>>>> fastdebug
>>>>>>> build of Zero with --disable-precompiled-headers that failed to
>>>>>>> build
>>>>>>> without and built fine with the fix.
>>>>>> I could check in just the deoptimization.hpp change and build only
>>>>>> fastdebug until the other bug is fixed.
>>>>> This sounds good to me.
>>>>>
>>>>>>> Coleen, do you have details about the failure which gets supposedly
>>>>>>> fixed by the other hunk?
>>>>>> The only thing I have is the g++ compilation failures without these
>>>>>> changes.  The one that was fixed by including allocation.inline.hpp
>>>>>> was:
>>>>>>
>>>>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>>>>> release'
>>>>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>>>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>>>>>> ats.hpp:32:
>>>>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>>>>> delete(void*)'
>>>>>> collect2: error: ld returned 1 exit status
>>>>>>
>>>>>> Since the destructor is complaining about the missing delete
>>>>>> operator, I
>>>>>> assume this compiler has the sort of destructor that implicitly can
>>>>>> also
>>>>>> call delete.  I don't have any other information or ideas really why
>>>>>> this fails to compile.
>>>>> Thanks!
>>>>>
>>>>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>>>>> deoptimization.hpp change a Zero JVM builds fine here in all variants:
>>>>> release/fastdebug/slowdebug.
>>>>>
>>>>> $ gcc --version
>>>>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>>>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>>>> This is free software; see the source for copying conditions. There
>>>>> is NO
>>>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>>>> PURPOSE.
>>>>>
>>>>> Thanks,
>>>>> Severin
>>>>
>>>
>