RFR: 8151841: Build needs additional flags to compile with GCC 6

Kim Barrett kim.barrett at oracle.com
Tue Mar 15 19:15:32 UTC 2016

> On Mar 15, 2016, at 12:18 AM, Andrew Hughes <gnu.andrew at redhat.com> wrote:

I’ll probably have more to say later; just responding to one point here.

>>> 2. A number of optimisations in GCC 6 lead to a broken JVM. We need to
>>> add -fno-delete-null-pointer-checks and -fno-lifetime-dse to get a
>>> working JVM.
>> That's very disturbing!
> Andrew Haley (CCed) has more details on the need for these options,
> as he diagnosed the reason for the crash, with the help of the GCC
> developers. From what I understand of it, it is a case of more
> aggressive optimisations in the new GCC running into problems with
> code that doesn't strictly conform to the specification and exhibit
> undefined behaviour.

That is my suspicion too, though without more detail of the failures it’s
hard to completely discount the possibility of compiler bugs.

> The need for -flifetime-dse is covered in 
> comment #47 of the bug for this [0]; "an object field [is] being
> accessed before the object is constructed, in breach of
> C++98 [class.cdtor]”.

Thanks for the pointer to the redhat bug for tracking this work:

[Though a lot of comments there aren't visible to me.]

This comment is quite worrisome.
  I very strongly suspect that -fno-strict-aliasing is broken in this
  version of GCC.

Is that still thought to be a concern?  Or are the problems
encountered covered by the two suggested -fno-<option> changes?

All the comments (that are visible to me) in that bug thread seem to
be about JDK 8.  Are things any different in JDK 9?

For example, the problematic function mentioned in comment 6 of that

inline void* operator new( size_t x, Compile* C) throw() {
   Node* n = (Node*)C->node_arena()->Amalloc_D(x);
#ifdef ASSERT
   n->_in = (Node**)n; // magic cookie for assertion check
   n->_out = (Node**)C;
   __asm__ volatile("nop" : : : "memory");  // --- possible workaround for gcc6
   return (void*)n;

has been changed in JDK 9.  The problematic assignment of n->_out is
no longer present in JDK9 (and the associated argument is also gone).
Though the ASSERT-conditionalized assignment of n-_in is also wrong,
and could be affected by -f[no-]lifetime-dse.

I think a local change focused on that function could be made,
possibly avoiding a global change to the compilation options.  I don't
have a suggestion for how to correctly eliminate the problematic
assignment, since I'm not really familiar with this code, but I think
a local application of -fno-lifetime-dse could be made via an
__attribute__, e.g. something like


if I'm understanding the gcc documentation correctly.

Another option for JDK 9 would be to -fno-lifetime-dse only for
[fast]debug builds, since the problematic code is ASSERT-only.  I'm
not wild about that, and it wouldn't help for JDK 8.  But I mention it
for completeness.

Of course, this suggestion of a local workaround assumes there aren't
lots more of these, but that seems like a plausible guess.  But maybe
those hidden comments provide more information about that.

And any more information about why -fno-delete-null-pointer-checks

More information about the hotspot-dev mailing list