JDK-8160310: HotSpot cannot be built with GCC 6

[Yasumasa Suenaga]

Hi David,

I added subtasks to JDK-8160310.


>>   Group 5: potential for SEGV
>>     - classLoaderData.cpp
>
> Would like to know how gcc 6 relates to this one.

I'm not sure this crash relates to GCC 6, but I think NULL check should be added at this point.


Thanks,

Yasumasa


On 2016/06/27 20:36, David Holmes wrote:
> On 27/06/2016 8:25 PM, Yasumasa Suenaga wrote:
>>> But these need to be broken up into individual problems. I don't mind
>>> if the actual compilation warnings/errors are handled as a group.
>>
>> I think we can create several subtasks for this as below:
>
> Seems reasonable.
>
>>   Group 1: narrowing conversion
>>     - altHashing.cpp
>>     - os_linux.cpp
>>     - type.cpp
>>
>>   Group 2: uninitialized value (including assertion failure)
>>     - assembler_x86.cpp
>>     - interp_masm_x86.cpp
>>     - relocInfo.hpp
>>     - c1_Instruction.hpp
>>
>>   Group 3: invalid suffix on literal
>>     - moduleEntry.cpp
>>     - packageEntry.cpp
>>     - preservedMarks.cpp
>>
>>   Group 4: unnescessary assertion
>>     - node.cpp
>>
>>   Group 5: potential for SEGV
>>     - classLoaderData.cpp
>
> Would like to know how gcc 6 relates to this one.
>
>>   Group 6: refactoring for GCC 6
>>     - oop.inline.hpp
>>
>>
>> Is it okay?
>> If so, I will create them as subtask of JDK-8160310 and send
>> review request if possible.
>
> I'm okay with that.
>
> Thanks,
> David
>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/06/27 13:08, David Holmes wrote:
>>> On 27/06/2016 1:57 PM, Yasumasa Suenaga wrote:
>>>> Hi David, Kim,
>>>>
>>>> I've filed this as JDK-8160310, and uploaded new webrev for discussion.
>>>> (Not review request)
>>>>
>>>>   http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot.01/
>>>>
>>>>
>>>>> Some of these appear to be just plain bug fixes, and I wonder why the
>>>>> code is working now?  For example, the change at
>>>>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious.
>>>>
>>>> I analyzed this crash with GDB, and this fix works fine.
>>>
>>> Yes but it has nothing to do with gcc 6. AFAICS a very early GC during
>>> module initialization would trigger this bug.
>>>
>>> I'd be very surprised if any of the crashes are directly attributable
>>> to using gcc 6. But these need to be broken up into individual
>>> problems. I don't mind if the actual compilation warnings/errors are
>>> handled as a group.
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>> Please see hs_err log on JIRA.
>>>>
>>>>
>>>>> Some of these are just cleanups, like
>>>>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC.
>>>>
>>>> I understood.
>>>> But I do not understand well why this cheange works fine.
>>>> So I want to discuss about it.
>>>> (I uploaded hs_err log to JIRA.)
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2016/06/27 12:40, Kim Barrett wrote:
>>>>>> On Jun 25, 2016, at 9:57 AM, Yasumasa Suenaga <yasuenag at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> This review request relates to [1].
>>>>>>
>>>>>> I've tried to build OpenJDK 9 at Fedora 24 x64.
>>>>>> Fedora 24 has GCC 6.1.1, and OpenJDK 9 build was failed.
>>>>>>
>>>>>> I fixed build error and several issues (VM crash and internal error)
>>>>>> as below:
>>>>>>
>>>>>>  http://cr.openjdk.java.net/~ysuenaga/jdk9-for-gcc6/hotspot/
>>>>>
>>>>> I've only done a quick skim of the proposed hotspot changes, not a
>>>>> proper review.  Just in general, I'd rather review changes in chunks
>>>>> that were logically related, which many of these aren't.  (Needed to
>>>>> build and run with some new compiler doesn't make them related for
>>>>> review purposes.)  And please provide some context.  Reviewers
>>>>> shouldn't have to guess what problem is being solved by a given
>>>>> change. Some of these still seem mysterious to me, even with the link
>>>>> to build failures and crash dumps.
>>>>>
>>>>> Some specific issues:
>>>>>
>>>>> A couple of these were recently addressed by JDK-8157758.
>>>>>
>>>>> Some of these are C++11 or later changes tripping up a code base
>>>>> written for C++98/03.  A few months ago a change was made to
>>>>> explicitly use -std=gnu++98 for exactly this reason (see JDK-8151841),
>>>>> but that seems to have gotten lost in the transition to the new build
>>>>> system (see JDK-8156980).  I would prefer that got fixed and these
>>>>> kinds of issues be deferred to a future modernization project, where
>>>>> some of them might involve something more principled than adding some
>>>>> workaround casts, for example. (We've been doing string/identifier
>>>>> whitespace separation for a while, though; I'd be fine with those,
>>>>> other than being post-FC.)
>>>>>
>>>>> Some of these appear to be just plain bug fixes, and I wonder why the
>>>>> code is working now?  For example, the change at
>>>>> src/share/vm/classfile/classLoaderData.cpp:145 seems suspicious.
>>>>>
>>>>> Some of these are just cleanups, like
>>>>> src/share/vm/oops/oop.inline.hpp:542, but it's post-FC.
>>>>>
>>>>>> Does someone work for it?
>>>>>> If no one works for it, I will file it to JBS and will send review
>>>>>> request.
>>>>>
>>>>> Certainly there should be CRs filed for these; the enhancements so
>>>>> they don't get lost, and the crashes because they probably indicate
>>>>> real bugs.
>>>>>
>>>>>> For jdk repos, I've sent review request [2].
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html
>>>>>> [2]
>>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2016-June/007081.html
>>>>>
>>>>>