JDK-8160310: HotSpot cannot be built with GCC 6

[David Holmes]

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