[PATCH 4/4 v2] fix build errors with gcc6

Andrew Hughes gnu.andrew at redhat.com
Mon May 16 15:18:37 UTC 2016



----- Original Message -----
> On 12/05/2016 10:56 AM, Guido Trentalancia wrote:
> > Hello David !
> >
> > Thanks very much for your expert advice...
> >
> > On Thu, 12/05/2016 at 08.47 +1000, David Holmes wrote:
> >> Hi Guido,
> >>
> >> I don't see how a backport of 8068975 can be considered "fixing
> >> build
> >> errors with gcc6". patches like that build on other changes that are
> >> in
> >> 9 but not in 8.
> >
> > That's the reason of the runtime error !
> >
> >>  I would not expect that backport to be approved as it
> >> removes part of the Unsafe API.
> >
> > Here is a revised, essential 4/4 patch that should work (no runtime
> > crash):
> >
> > The following (RFC) patch aims to fix the following build error
> > with gcc6:
> >
> > /home/guido/new/openjdk/mercurial-rep/jdk8u-build1/hotspot/src/share/vm/prims/unsafe.cpp:1378:17:
> > error: unable to find string literal operator ‘operator""OBJ’ with ‘const
> > char [40]’, ‘long unsigned int’ arguments
> >  #define CLS LANG"Class;"
> >                  ^
> > /home/guido/new/openjdk/mercurial-rep/jdk8u-build1/hotspot/src/share/vm/prims/unsafe.cpp:1696:48:
> > note: in expansion of macro ‘CLS’
> >      {CC"defineAnonymousClass", CC"("DAC_Args")"CLS,
> >      FN_PTR(Unsafe_DefineAnonymousClass)},
> >                                                 ^~~
> >
> > It should be a backport from openjdk9 of the following:
> >
> > changeset:   8638:767f36deb0dc
> > parent:      8599:3ebc4f430a74
> > user:        bpittore
> > date:        Wed Jun 24 12:12:25 2015 -0400
> > summary:     8081202: Hotspot compile warning: "Invalid suffix on literal;
> > C++11 requires a space between literal and identifier"
> 
> That is a much more appropriate backport. But as Andrew Hughes said this
> is likely already in the pipeline.
> 
> David
> ------
> 

While I agree that is a suitable and unproblematic backport, my approach
so far has been to continue building with the older C++ standard, which
means explicitly requesting it on newer versions of GCC where the default
has changed. That's what my fix, 8151841, did. You could potentially look
at supporting C++11 in OpenJDK 9, but I don't think it's appropriate for
earlier versions. Even if sufficient changes can be made to get OpenJDK
to build and run (and there were a lot of failures when I looked), it
results in changing the ABI of the resulting binaries. All in all, I think
it's too risky to resolve in older JDKs in that way, and I'd prefer to
just retain existing behaviour as much as possible.

It seems that you're still seeing breakage on 9 because the new HotSpot
build system has gone in and regressed some of 8151841 (see [0]). I'm
looking at fixing this now, and will also see about backporting 8151841
to 8u.

[0] https://bugs.openjdk.java.net/browse/JDK-8156980
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222




More information about the jdk8u-dev mailing list