RFR (s) 8141570: Fix Zero interpreter build for --disable-precompiled-headers
Coleen Phillimore
coleen.phillimore at oracle.com
Tue Nov 17 02:47:04 UTC 2015
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.
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
>>>
>>
More information about the hotspot-dev
mailing list