> On Mar 15, 2016, at 12:18 AM, Andrew Hughes <gnu.and...@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: https://bugzilla.redhat.com/show_bug.cgi?id=1306558 [Though a lot of comments there aren't visible to me.] This comment is quite worrisome. https://bugzilla.redhat.com/show_bug.cgi?id=1306558#c6 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 thread: 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 #endif 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 __attribute__((optimize("no-lifetime-dse"))) 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 matters?
