Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

2016-07-07 Thread Andrew Hughes 


- Original Message -
> > On Jul 7, 2016, at 1:48 PM, Andrew Hughes  wrote:
> >>> Revised webrevs:
> >>> 
> >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root
> >>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot
> >> 
> >> These look good to me.
> >> 
> > 
> > Minor revision:
> > 
> > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root
> > http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot
> > 
> > I spotted that jsig is just a single C file and so doesn't
> > need the -std flag. In fact, it complains about it:
> > 
> > Compiling jsig.c (for libjsig.so)
> > ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2
> > -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\
> > MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o
> > /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\
> > rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c >
> > >(/usr/bin/tee /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\
> > g.o.log) 2> >(/usr/bin/tee
> > /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || (
> > exitcode=$? && /bin/cp /home/and\
> > rew/builder/dev/hotspot/libjsig/objs/jsig.o.log
> > /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\
> > .log && exit $exitcode ) ) && wait )
> > cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++
> > but not for C
> > 
> > So just ADLC is fixed now.
> > 
> > The root webrev is the same as before.
> 
> Oops, glad you caught that.
> 
> Looks even better.
> 
> 

The same warning was causing an error in the OpenJDK 8 backport of the original
GCC 6 patch, so I double-checked the logs for 9 and spotted this :-)
-- 
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

[8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6

2016-07-07 Thread Andrew Hughes 
Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8151841

This is a backport of the original fix to support building OpenJDK
with GCC 6. It was necessary to cherry-pick parts of a number of
earlier fixes to make this work with the build system in 8:

8149647: Incremental enhancements from build-infra
8032045: Enable compiler and linker safety switches for debug builds

and so I'm requesting a review of the 8 version of the patch here as well
as approval for 8u.

In brief, the patch makes OpenJDK build with GCC 6 by explicitly specifying
the C++ standard to use (-std=gnu++98) and disabling two optimisations with
-fno-lifetime-dse and -fno-delete-null-pointer-checks. Further information
on the changes is available in the GCC 6 release notes [0]. GCC 6 uses
a newer C++ standard, C++14, with which the OpenJDK codebase is not yet
compliant. The simplest way to fix this, especially for existing releases,
is to explicitly request the previous default, gnu++98. The deletion
of null pointer checks and more aggressive lifetime dead store elimination
in 6 lead to a crashing virtual machine being built, so we disable them
if GCC >= 6 is used.

To make the original patch work with 8u, a number of changes from other
fixes had to also be brought over:

* We need to check we are using GCC 6 or above, so we need to bring
over the TOOLCHAIN_CHECK_COMPILER_VERSION and
TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. 
TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional
numbered rather than named argument macro so we don't need to backport
BASIC_DEFUN_NAMED.
* We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245
as we need to apply the -std option only to the C++ compiler, not the
C compiler. If passed to the C compiler, it will produce a warning,
and this is converted to an error at one point in the build
(a -Werror in libsctp).

Generally, we've kept things in toolchain.m4 (8034788 introduced flags.m4,
separating out some code, and so many of these changes are in that file
in 9) and avoid named argument macros. Otherwise, it's largely the
same as the 9 version. We have adopted the longer name for
the -fno-delete-null-pointer-checks flag variable as suggested in the
review of the update to this patch for the new HotSpot build [1].

[0] https://gcc.gnu.org/gcc-6/porting_to.html
[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html
-- 
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

Re: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt

2016-07-07 Thread Phil Race 

On 07/07/2016 10:25 AM, Semyon Sadetsky wrote:

On 7/7/2016 7:48 PM, Ajit Ghaisas wrote:


Thanks Phil for the review.
Please find my answers below.

Semyon, can you please comment on Phil's question below?

I agree with this change. The check is not needed.


Ok. so the fix overall seems fine in that case although regarding

>but it is out of purview of this fix as it may introduce behavioral 
change.


I do not entirely buy it is out of purview I won't push any further on 
it for now

but won't be surprised if someone else reports an unused variable warning.


-phil.



--Semyon


Regards,
Ajit

-Original Message-
From: Phil Race
Sent: Wednesday, July 06, 2016 2:02 AM
To: Ajit Ghaisas
Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-...@openjdk.java.net; 
build-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for 
libawt_xawt


It is not always clear to me what warning is being suppressed and why 
you have chosen a particular solution/action



this next one looks like it might introduce an unused variable warning.
What was it solving ? That the code was not checking a return value ?

size_t bytesWritten = write ( AWT_WRITEPIPE, _char, 1 ); 
//bytesWritten is unused


Isn't the compiler's point here that you *should* be doing something 
with the result?

Not just ignoring it differently ...

--
[Ajit] : there was a warning of type 'unused-result' for write() 
method. Now, I have just assigned that to a variable which fixes the 
warning.
I think, we should have some code to do error check on bytesWritten 
and return it - but it is out of purview of this fix as it may 
introduce behavioral change.

--

-

and this one ? I want Semyon to comment on what this code is trying 
to do in its original form since it was added for GTK3.


@@ -1989,11 +2029,7 @@
   static guint8 recode_color(gdouble channel)
   {
   guint16 result = (guint16)(channel * 65535);
-if (result < 0) {
-result = 0;
-} else if (result > 65535) {
-result = 65535;
-}
+
   return (guint8)( result >> 8);
   }

-
[Ajit] : there was a warning about guint16 will not be less than 0 
and larger than 65535. Hence I have removed code checking this range.

-

-


-phil.

On 06/23/2016 12:09 AM, Ajit Ghaisas wrote:

Hi,

Bug :
  https://bugs.openjdk.java.net/browse/JDK-8074824
  (Resolve disabled warnings for libawt_xawt)

As part of fixing this bug, I have -

  1. Fixed warnings in source code after removing blanket 
warning suppressions from makefile.


  2. In case the warning fix is not possible, converted blanket 
warning suppression for this library to suppression of warnings for 
individual files.


  3. Added comments in makefile for the warning suppression that 
cannot be fixed.


 One type of gcc warning 'deprecated-declarations' will be fixed
separately (as part of JDK-8160146)


I have built the changes successfully on all supported platforms.


Webrev :
  http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/

Request you to review.

Regards,
Ajit

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

2016-07-07 Thread Kim Barrett 
> On Jul 7, 2016, at 1:48 PM, Andrew Hughes  wrote:
>>> Revised webrevs:
>>> 
>>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root
>>> http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot
>> 
>> These look good to me.
>> 
> 
> Minor revision:
> 
> http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root
> http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot
> 
> I spotted that jsig is just a single C file and so doesn't
> need the -std flag. In fact, it complains about it:
> 
> Compiling jsig.c (for libjsig.so)
> ( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 
> -std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\
> MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o 
> /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\
> rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > >(/usr/bin/tee 
> /home/andrew/builder/dev/hotspot/libjsig/objs/jsi\
> g.o.log) 2> >(/usr/bin/tee 
> /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( 
> exitcode=$? && /bin/cp /home/and\
> rew/builder/dev/hotspot/libjsig/objs/jsig.o.log 
> /home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\
> .log && exit $exitcode ) ) && wait )
> cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but 
> not for C
> 
> So just ADLC is fixed now.
> 
> The root webrev is the same as before.

Oops, glad you caught that.

Looks even better.

Re: Building JDK9 fails on OS X El Capitan

2016-07-07 Thread Phil Race 

I expect this is the SDK version you are using more than the OS version.
10.9 is the supported SDK.

Any changes to this particular code should be discussed on 
2d-...@openjdk.java.net

since they would not be build changes

But that might not be sufficient .. you could encounter other issues that
limit the ability to build using whatever SDK you have.

-phil.


On 07/07/2016 11:31 AM, Robin Stevens wrote:

Hello,

it is currently not possible to build JDK9 on OS X El Capitan.

The problem is the line

#include 

in files

jdk/src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m
jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m

On OS X El Capitan, the Accelerate.h file contains

#ifndef __VECLIB__
#include 
#endif

where vecLib.h contains

#error "The vecLib framework is deprecated. Please include
 instead of  and link to the
Accelerate framework instead of the vecLib framework."

This is also the error with which the build fails.

Adding

#define __VECLIB__

to the two aforementioned files resolves the error, as it avoids that the
Accelerate.h file loads the vecLib.h file.

I have no idea of the impact of adding #define __VECLIB__ , and what it
might break.
The purpose of this email is more to ensure that other people who stumble
against the same problem can find a solution using Google.

Regards,

Robin

Building JDK9 fails on OS X El Capitan

2016-07-07 Thread Robin Stevens 
Hello,

it is currently not possible to build JDK9 on OS X El Capitan.

The problem is the line

#include 

in files

jdk/src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m
jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m

On OS X El Capitan, the Accelerate.h file contains

#ifndef __VECLIB__
#include 
#endif

where vecLib.h contains

#error "The vecLib framework is deprecated. Please include
 instead of  and link to the
Accelerate framework instead of the vecLib framework."

This is also the error with which the build fails.

Adding

#define __VECLIB__

to the two aforementioned files resolves the error, as it avoids that the
Accelerate.h file loads the vecLib.h file.

I have no idea of the impact of adding #define __VECLIB__ , and what it
might break.
The purpose of this email is more to ensure that other people who stumble
against the same problem can find a solution using Google.

Regards,

Robin

Building JDK8 fails on OS X El Capitan: clang process gets stuck

2016-07-07 Thread Robin Stevens 
Hello,

if you follow the build instructions to the letter (
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/file/817d9fb584ba/README-builds.html),
and try building JDK with XCode version 4.5.2 on El Capitan, the build
never ends.

At a certain point, you have a number of "clang" processes each consuming
one CPU core for 100% which never end.

Using XCode version 4.6.3 solves the issue.

Can this be added to the build instructions ? It would have saved me a
considerable amount of time if this would have been mentioned in the
documentation.

Thanks,

Robin

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

2016-07-07 Thread Andrew Hughes 
snip...

> 
> > Revised webrevs:
> > 
> > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/root
> > http://cr.openjdk.java.net/~andrew/8156980/webrev.04/hotspot
> 
> These look good to me.
> 

Minor revision:

http://cr.openjdk.java.net/~andrew/8156980/webrev.05/root
http://cr.openjdk.java.net/~andrew/8156980/webrev.05/hotspot

I spotted that jsig is just a single C file and so doesn't
need the -std flag. In fact, it complains about it:

Compiling jsig.c (for libjsig.so)
( ( /usr/bin/gcc -fPIC -D_GNU_SOURCE -D_REENTRANT -O2 -pipe -march=core2 
-std=gnu++98 -m64 -g -DTHIS_FILE='"jsig.c"' -c -MMD -\
MF /home/andrew/builder/dev/hotspot/libjsig/objs/jsig.d -o 
/home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o /home/andrew/p\
rojects/openjdk/upstream/dev/hotspot/src/os/linux/vm/jsig.c > >(/usr/bin/tee 
/home/andrew/builder/dev/hotspot/libjsig/objs/jsi\
g.o.log) 2> >(/usr/bin/tee 
/home/andrew/builder/dev/hotspot/libjsig/objs/jsig.o.log >&2) || ( exitcode=$? 
&& /bin/cp /home/and\
rew/builder/dev/hotspot/libjsig/objs/jsig.o.log 
/home/andrew/builder/dev/make-support/failure-logs/hotspot_libjsig_objs_jsig.o\
.log && exit $exitcode ) ) && wait )
cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but 
not for C

So just ADLC is fixed now.

The root webrev is the same as before.
-- 
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

Re: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt

2016-07-07 Thread Semyon Sadetsky 

On 7/7/2016 7:48 PM, Ajit Ghaisas wrote:


Thanks Phil for the review.
Please find my answers below.

Semyon, can you please comment on Phil's question below?

I agree with this change. The check is not needed.

--Semyon


Regards,
Ajit

-Original Message-
From: Phil Race
Sent: Wednesday, July 06, 2016 2:02 AM
To: Ajit Ghaisas
Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-...@openjdk.java.net; 
build-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt

It is not always clear to me what warning is being suppressed and why you have 
chosen a particular solution/action


this next one looks like it might introduce an unused variable warning.
What was it solving ? That the code was not checking a return value ?

size_t bytesWritten = write ( AWT_WRITEPIPE, _char, 1 ); //bytesWritten 
is unused

Isn't the compiler's point here that you *should* be doing something with the 
result?
Not just ignoring it differently ...

--
[Ajit] : there was a warning of type 'unused-result' for write() method. Now, I 
have just assigned that to a variable which fixes the warning.
I think, we should have some code to do error check on bytesWritten and return 
it - but it is out of purview of this fix as it may introduce behavioral change.
--

-

and this one ? I want Semyon to comment on what this code is trying to do in 
its original form since it was added for GTK3.

@@ -1989,11 +2029,7 @@
   static guint8 recode_color(gdouble channel)
   {
   guint16 result = (guint16)(channel * 65535);
-if (result < 0) {
-result = 0;
-} else if (result > 65535) {
-result = 65535;
-}
+
   return (guint8)( result >> 8);
   }

-
[Ajit] : there was a warning about guint16 will not be less than 0 and larger 
than 65535. Hence I have removed code checking this range.
-

-


-phil.

On 06/23/2016 12:09 AM, Ajit Ghaisas wrote:

Hi,

Bug :
  https://bugs.openjdk.java.net/browse/JDK-8074824
  (Resolve disabled warnings for libawt_xawt)

As part of fixing this bug, I have -

  1. Fixed warnings in source code after removing blanket warning 
suppressions from makefile.

  2. In case the warning fix is not possible, converted blanket warning 
suppression for this library to suppression of warnings for individual files.

  3. Added comments in makefile for the warning suppression that cannot be 
fixed.

 One type of gcc warning 'deprecated-declarations' will be fixed
separately (as part of JDK-8160146)


I have built the changes successfully on all supported platforms.


Webrev :
  http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/

Request you to review.

Regards,
Ajit

RE: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt

2016-07-07 Thread Ajit Ghaisas 
Thanks Phil for the review.
Please find my answers below.

Semyon, can you please comment on Phil's question below?

Regards,
Ajit

-Original Message-
From: Phil Race 
Sent: Wednesday, July 06, 2016 2:02 AM
To: Ajit Ghaisas
Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-...@openjdk.java.net; 
build-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for libawt_xawt

It is not always clear to me what warning is being suppressed and why you have 
chosen a particular solution/action


this next one looks like it might introduce an unused variable warning.
What was it solving ? That the code was not checking a return value ?

size_t bytesWritten = write ( AWT_WRITEPIPE, _char, 1 ); //bytesWritten 
is unused

Isn't the compiler's point here that you *should* be doing something with the 
result?
Not just ignoring it differently ...

--
[Ajit] : there was a warning of type 'unused-result' for write() method. Now, I 
have just assigned that to a variable which fixes the warning.
I think, we should have some code to do error check on bytesWritten and return 
it - but it is out of purview of this fix as it may introduce behavioral change.
--

-

and this one ? I want Semyon to comment on what this code is trying to do in 
its original form since it was added for GTK3.

@@ -1989,11 +2029,7 @@
  static guint8 recode_color(gdouble channel)
  {
  guint16 result = (guint16)(channel * 65535);
-if (result < 0) {
-result = 0;
-} else if (result > 65535) {
-result = 65535;
-}
+
  return (guint8)( result >> 8);
  }

-
[Ajit] : there was a warning about guint16 will not be less than 0 and larger 
than 65535. Hence I have removed code checking this range.
-

-


-phil.

On 06/23/2016 12:09 AM, Ajit Ghaisas wrote:
> Hi,
>
> Bug :
>  https://bugs.openjdk.java.net/browse/JDK-8074824
>  (Resolve disabled warnings for libawt_xawt)
>
> As part of fixing this bug, I have -
>
>  1. Fixed warnings in source code after removing blanket warning 
> suppressions from makefile.
>
>  2. In case the warning fix is not possible, converted blanket warning 
> suppression for this library to suppression of warnings for individual files.
>
>  3. Added comments in makefile for the warning suppression that cannot be 
> fixed.
>
> One type of gcc warning 'deprecated-declarations' will be fixed 
> separately (as part of JDK-8160146)
>
>
> I have built the changes successfully on all supported platforms.
>
>
> Webrev :
>  http://cr.openjdk.java.net/~aghaisas/8074824/webrev.00/
>
> Request you to review.
>
> Regards,
> Ajit

Re: [RFR] JDK-8156980: Hotspot build doesn't have -std=gnu++98 gcc option

2016-07-07 Thread Andrew Hughes 
snip...

> > > I'm also now seeing a problem with GCC 6 only that is unique to the
> > > latest
> > > OpenJDK 9
> > > and what looks like the gtest code. It seems to be the result of the
> > > header
> > > changes
> > > also documented in [0] which were introduced in January [1] (and so
> > > probably weren't
> > > in earlier test versions of GCC 6). I'm able to work around it and get a
> > > completed
> > > build by setting -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS, so it seems to be
> > > something
> > > to do with the changes to stdlib.h in GCC 6. Something for a separate
> > > bug.
> > 
> > What fun!
> 
> A new batch of changes just came through which seems to have fixed it.
> I'm guessing this one:
> 
> http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7862a718ec47
> 
> Either way, I'm happy I don't have to debug it :-)
> 

Sadly, I celebrated too soon; it seems that change just delayed the failure
until much later in the build.

I've found the problem though. In src/share/vm/utilities/globalDefinitions.hpp,
we have:

#ifdef max
#undef max
#endif

#ifdef min
#undef min
#endif

#define max(a,b) Do_not_use_max_use_MAX2_instead
#define min(a,b) Do_not_use_min_use_MIN2_instead

The problem is that max and min are now longer macros in the GCC 6 C++ library.
So they can't be undefined.

The build succeeds if I disable (#if 0) the definition of max and min. So
we need to consider either removing them or _GLIBCXX_INCLUDE_NEXT_C_HEADERS
needs to be defined to get the old behaviour. I prefer the former.

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

Re: RFR: 8160825 Update minimum Solaris Studio compiler version to 5.13

2016-07-07 Thread Tim Bell 

Hello Stefan:

This is a small change, to update the ckeck in configure to warn if 
the required Solaris Studio Compiler 5.13 is not available (As stated 
in the README-builds.html).



http://cr.openjdk.java.net/~sanzinger/8160825/webrev.00/


Looks good.  Sun Studio 12.4 contains the C++ 5.13 compiler:

% devkit/SS12u4-Solaris11u1/SS12u4/bin/CC -V
CC: Sun C++ 5.13 SunOS_i386 151846-10 2015/10/30

Since this change is in an open .m4 file, remember to run 
common/autoconf/autogen.sh and then push both open and closed 
generated-configure.sh files.


Tim

RFR: 8160825 Update minimum Solaris Studio compiler version to 5.13

2016-07-07 Thread Stefan Anzinger 
This is a small change, to update the ckeck in configure to warn if the 
required Solaris Studio Compiler 5.13 is not available (As stated in the 
README-builds.html).


http://cr.openjdk.java.net/~sanzinger/8160825/webrev.00/

Stefan