JDK-8160310: HotSpot cannot be built with GCC 6

[Yasumasa Suenaga]

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

   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

   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.


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