JDK-8160310: HotSpot cannot be built with GCC 6

[David Holmes]

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
>>>>
>>>>