Re: Solaris sparc build issue with OpenJDK 11(+28): /usr/gnu/bin/nm: jvmciCompilerToVMInit.o: Bad value

2018-09-06 Thread David Holmes 

Hi Petr,

On 7/09/2018 4:28 AM, Petr Sumbera wrote:

Hi,

I'm seeing this with sparc build (on Solaris trunk). On intel it builds 
just fine.


gmake[4]: Entering directory 
'/builds2/psumbera/userland-openjdk/components/openjdk-11/jdk-11-76072a077ee1/make/gensrc' 


Compiling 89 properties into resource bundles for java.desktop
Compiling 2986 files for java.base
gmake[4]: Leaving directory 
'/builds2/psumbera/userland-openjdk/components/openjdk-11/jdk-11-76072a077ee1/make/gensrc' 

/usr/gnu/bin/nm: jvmciCompilerToVMInit.o: no group info for section 


What toolchain are you trying to use here? We use nm that comes from 
Solaris Studio 12u4 (using an internal devkit).


David

'.group%__1cRResourceHashtable4ClnGHandle_cOprimitive_hash4Cl_6FrkTA_I_cQprimitive_equals4Cl_6Frk05_b_ujWeBnLResourceObjPallocation_type_eHnKMemoryType__Dget6kMrkl_pn0A__' 



/usr/gnu/bin/nm: jvmciCompilerToVMInit.o: no group info for section 
'.group%__1cRResourceHashtable4ClnGHandle_cOprimitive_hash4Cl_6FrkTA_I_cQprimitive_equals4Cl_6Frk05_b_ujWeBnLResourceObjPallocation_type_eHnKMemoryType__Dget6kMrkl_pn0A__' 


/usr/gnu/bin/nm: jvmciCompilerToVMInit.o: Bad value
gmake[4]: *** [lib/JvmMapfile.gmk:142: 
/builds2/psumbera/userland-openjdk/components/openjdk-11/build/sparcv9/hotspot/variant-server/libjvm/symbols-objects] 
Error 1


Anyone seen this?

Thanks,

Petr

Re: RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization

2018-09-06 Thread David Holmes 

On 7/09/2018 12:32 AM, Severin Gehwolf wrote:

Hi,

On Thu, 2018-09-06 at 07:29 +1000, David Holmes wrote:

Hi Severin,

On 6/09/2018 4:36 AM, Severin Gehwolf wrote:

Hi,

On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get
compiled with -O0. It appears to be for the same (historical?) reason
as for fdlibm files in core-libs. JDK-8210416 is an attempt to make
this consistent on all Linux arches (as s390x/ppc64/aarch64 already use
that) for fdlibm. This patch does the same for the hotspot copies.
Compile it with OPT and -ffp-contract=off instead of no optimization at
all. Thoughts?


The code in sharedRuntimeTrig is expected/required to be built the same
way as the fdlibm library as it contains the same code. So if it is okay
to change the way fdlibm is built then it follows this is okay too. I
traced this change to the optimization flags back to 2001 but no details
on the exact issue seen with fdlibm.


Right. I should note that ppc64, s390x and aarch64 ports don't have
this optimization turned off as those overrides are in a x86 specific
block. It appears it hasn't caused issues for these ports so far.

Your comment on JDK-8210416 says that it was introduced for an issue on
GCC 1.1.1 i386 back in 1998. Wow ;-)


Is -ffp-contract=off a gcc-specific flag? If so this should be a gcc
conditional not a linux-x86 one.


clang has it (as noted elsewhere), but I don't know which version.
What's the "blessed" clang version for JDK 12?


I've no idea sorry.

Once 8210416 has settled on the right approach for the makefiles the 
same can be applied here.


Thanks,
David


Thanks,
Severin


webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.01/
Bug:https://bugs.openjdk.java.net/browse/JDK-8210425

Testing: - make run-test-tier1 (no new failures).
   - Currently running through submit.
   - Verified objects get compiled with -O3 -ffp-contract=off in
 build logs.

Thanks,
Severin

Re: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary

2018-09-06 Thread Jiangli Zhou 

Hi,

The JEP (http://openjdk.java.net/jeps/341) for the default CDS archives 
is now a candidate. Please see Mark's email, 'New candidate JEP: 341: 
Default CDS Archives'. Please help test Erik's makefile patch for your 
platform if it is not built/tested in openjdk mainline to prevent any 
possible breakage on your side. Any comments/feedbacks on the default 
CDS archive are highly appreciated!


  http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/

The above webrev is sync'ed with the lasted jdk/jdk repository today.

Thanks!

Jiangli

On 8/30/18 11:26 AM, Jiangli Zhou wrote:

Hi Magnus,

Sounds good. Will update the message.

Thanks!

Jiangli


On 8/30/18 3:56 AM, Magnus Ihse Bursie wrote:

On 2018-08-29 17:45, Erik Joelsson wrote:


Hello Magnus,

As the author of the build changes I will answer this.

On 2018-08-29 04:53, Magnus Ihse Bursie wrote:

On 2018-08-28 18:25, Erik Joelsson wrote:
Build changes look good to me (but should probably get review from 
someone else).


I'm (as usually) not as happy as Erik. ;-)

In Images.gmk, you have added this rule:
  $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO)

It took me a while to grasp. You are relying on 
$(JIMAGE_TARGET_FILE) to evaluate to bin/java. But that is only 
incidentally so. This file is just picked arbitrarily to represent 
when the entire image is done, for make. Please use 
$(JRE_IMAGE_DIR)/bin/java instead.



I can agree with this part. That was a bit of a hack done in a hurry.
The logic in jdk-options.m4 is broken. If indeed it is not possible 
to use cds archive with zero, then things will break since it will 
still be built if using --enable-cds-archive!


What you should do is to set default to true unless using cross 
compilation or zero. If the user explicitly sets 
--enable-cds-archive, and it's not possible, a fatal error should 
be generated.


Here I'm not as sure. I deliberately let it be possible to override 
the default behavior for zero as someone might want to fix that at 
some point, you never know. For cross compilation it's just not 
possible ever so that's different. Maybe my reasoning is invalid.


I see. I still think it would have made more sense, in that case, to 
set the default to false if using zero, but allow override. But I'm 
not going to insist on that.


However, if the problem with zero is not that it's technically 
impossible, just that it's not tested, I think the message should be 
changed from "[no, not possible with JVM variant zero]" to just 
"[no]" with a comment in the configure script that it's off by 
default since it's not tested.


Apart from that, Jiangli's latest webrev looks good.

Jiangli: If you fix it like I suggested, you do not need to respin 
the webrev.


/Magnus



/Erik

Apart from this, I'm more on Erik's line. :-)

/Magnus





/Erik


On 2018-08-27 13:33, Jiangli Zhou wrote:
Please review the implementation for JEP JDK-8204247 
(https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of 
the JEP is to include a default CDS archive in JDK 12 binary 
distribution (downloadable from http://jdk.java.net/12/). The 
default CDS archive is generated using the default classlist 
(resides in the lib/ directory) at JDK build time. Any 
comments/suggestions are highly appreciated.


All makefile changes in the webrev are contributed by Erik 
Joelsson (many thanks!!).


This is a combination of efforts from different teams and 
individuals. Thanks to everyone who has been involved in the JEP 
& implementation discussions, testing and bug fixing!


  JEP: https://bugs.openjdk.java.net/browse/JDK-8204247
  RFE: https://bugs.openjdk.java.net/browse/JDK-8202951
  webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/

Two sanity test cases for the default CDS archive are included 
test/hotspot/jtreg/runtime/SharedArchiveFile. They are not 
intended for in-depth CDS functional testing, which is already 
covered by the existing cds/appcds tests and all tiered tests 
executing with the default CDS archive enabled.


As part of the webrev, 
test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also 
fixed to use larger java heap (JDK-8209739

, https://bugs.openjdk.java.net/browse/JDK-8209739).

Tests executed:
 - several rounds of tier1 - tier8 via mach5
 - JCK lang, api and vm tests via mach5


Thanks!
Calvin, Ioi, Jiangli

Status of unshuffle

2018-09-06 Thread Martin Buchholz 
The unshuffle infrastructure in

./bin/unshuffle_patch.sh
./bin/unshuffle_list.txt

is highly version specific, and has naturally bitrotted.  Maybe it should
simply be removed from openjdk-current.

Maybe a more flexible version of unshuffle could be built that would work
for any source and dest versions, by using the SCM's file-renaming
metadata.  It looks like y'all were careful to preserve that metadata.  But
probably no one has time to work on such a tool.

Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

2018-09-06 Thread Erik Joelsson 



On 2018-09-06 10:29, Severin Gehwolf wrote:

On Thu, 2018-09-06 at 09:55 -0700, Erik Joelsson wrote:
Thanks, Erik. GCC supports -ffp-contract since 4.6. Clang has -ffp-
contract too. Question is beginning from which version. That's why I'd
expect for those flags to work on linux. Is there anything else I need
to check?

Would it be preferred if I moved this into a block like this?

ifeq ($(TOOLCHAIN_TYPE), gcc)
   [...]
endif
Yes, making it conditional on toolchain type is what David was after. 
You can also consider adding a capability check if you know that 
versions of the compiler that should still work don't have the feature.


/Erik

Thanks,
Severin


/Erik

Thanks,
Severin


Thanks,
David

On 5/09/2018 11:12 PM, Severin Gehwolf wrote:

Hi,

Cross-posting this review-thread on core-libs-dev and build-dev as
this
is a build change, but affects fdlibm which is core-libs.

With JDK-8170153 optimization for fdlibm code has been turned on
for
ppc64 s390 and aarch64. This patch intends to turn it on on all
arches
on Linux. I've not observed any precision issues. Is there a good
reason to not use -O3 -ffp-contract=off everywhere?

Bug:https://bugs.openjdk.java.net/browse/JDK-8210416
webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/

Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
- Currently running through submit repo.

A simple micro benchmark from JDK-8170153[1] shows these numbers
for
StrictMath:

Function  | before | after
--
sin   | 0m33.382s  | 0m18.731s
cos   | 0m31.562s  | 0m18.796s
tan   | 0m33.657s  | 0m21.093s
atan  | 0m5.714s   | 0m4.902s
log   | 0m6.212s   | 0m4.439s
log10 | 0m7.946s   | 0m5.543s
sqrt  | 0m0.481s   | 0m0.449s
cbrt  | 0m5.295s   | 0m5.214s
tanh  | 0m1.404s   | 0m1.307s
log1p | 0m6.457s   | 0m5.131s
IEEEremainder | 0m10.629s  | 0m6.048s
atan2 | 0m8.037s   | 0m5.668s
hypot | 0m2.171s   | 0m2.147s

Thoughts?

Thanks,
Severin

Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

2018-09-06 Thread Severin Gehwolf 
On Thu, 2018-09-06 at 09:55 -0700, Erik Joelsson wrote:
> On 2018-09-06 03:12, Severin Gehwolf wrote:
> > Hi David,
> > 
> > On Thu, 2018-09-06 at 07:32 +1000, David Holmes wrote:
> > > Hi Severin,
> > > 
> > > Might as well raise this here too as it's really a build philosophy
> > > issue. Shouldn't flags like -ffp-contract=off (and the existing AIX
> > > -qfloat=nomaf) be toolchain specific rather than platform specific?
> > 
> > Looks like Clang has -ffp-contract:
> > https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-ffp-contract
> > 
> > Is there any other (supported) toolchain other than gcc and clang on
> > linux? As for AIX I suppose there is only on supported toolchain?
> 
> We don't have a big variety of toolchain/platform combinations that we 
> actively support no, but we still try to be conscious of when a flag is 
> toolchain specific and when it's platform specific. There is certainly 
> interest in using other compilers on Linux, and GCC could potentially be 
> used on other platforms as well. Until we actually try it, it can be 
> hard to know for sure if a flag actually applies in other cases for the 
> toolchain and/or platform, but we can at least try our best guess.

Thanks, Erik. GCC supports -ffp-contract since 4.6. Clang has -ffp-
contract too. Question is beginning from which version. That's why I'd
expect for those flags to work on linux. Is there anything else I need
to check?

Would it be preferred if I moved this into a block like this?

ifeq ($(TOOLCHAIN_TYPE), gcc)
  [...]
endif

Thanks,
Severin

> /Erik
> > Thanks,
> > Severin
> > 
> > > Thanks,
> > > David
> > > 
> > > On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Cross-posting this review-thread on core-libs-dev and build-dev as
> > > > this
> > > > is a build change, but affects fdlibm which is core-libs.
> > > > 
> > > > With JDK-8170153 optimization for fdlibm code has been turned on
> > > > for
> > > > ppc64 s390 and aarch64. This patch intends to turn it on on all
> > > > arches
> > > > on Linux. I've not observed any precision issues. Is there a good
> > > > reason to not use -O3 -ffp-contract=off everywhere?
> > > > 
> > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8210416
> > > > webrev:
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
> > > > 
> > > > Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
> > > >- Currently running through submit repo.
> > > > 
> > > > A simple micro benchmark from JDK-8170153[1] shows these numbers
> > > > for
> > > > StrictMath:
> > > > 
> > > > Function  | before | after
> > > > --
> > > > sin   | 0m33.382s  | 0m18.731s
> > > > cos   | 0m31.562s  | 0m18.796s
> > > > tan   | 0m33.657s  | 0m21.093s
> > > > atan  | 0m5.714s   | 0m4.902s
> > > > log   | 0m6.212s   | 0m4.439s
> > > > log10 | 0m7.946s   | 0m5.543s
> > > > sqrt  | 0m0.481s   | 0m0.449s
> > > > cbrt  | 0m5.295s   | 0m5.214s
> > > > tanh  | 0m1.404s   | 0m1.307s
> > > > log1p | 0m6.457s   | 0m5.131s
> > > > IEEEremainder | 0m10.629s  | 0m6.048s
> > > > atan2 | 0m8.037s   | 0m5.668s
> > > > hypot | 0m2.171s   | 0m2.147s
> > > > 
> > > > Thoughts?
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > 
> 
>

Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

2018-09-06 Thread Erik Joelsson 



On 2018-09-06 03:12, Severin Gehwolf wrote:

Hi David,

On Thu, 2018-09-06 at 07:32 +1000, David Holmes wrote:

Hi Severin,

Might as well raise this here too as it's really a build philosophy
issue. Shouldn't flags like -ffp-contract=off (and the existing AIX
-qfloat=nomaf) be toolchain specific rather than platform specific?

Looks like Clang has -ffp-contract:
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-ffp-contract

Is there any other (supported) toolchain other than gcc and clang on
linux? As for AIX I suppose there is only on supported toolchain?
We don't have a big variety of toolchain/platform combinations that we 
actively support no, but we still try to be conscious of when a flag is 
toolchain specific and when it's platform specific. There is certainly 
interest in using other compilers on Linux, and GCC could potentially be 
used on other platforms as well. Until we actually try it, it can be 
hard to know for sure if a flag actually applies in other cases for the 
toolchain and/or platform, but we can at least try our best guess.


/Erik

Thanks,
Severin


Thanks,
David

On 5/09/2018 11:12 PM, Severin Gehwolf wrote:

Hi,

Cross-posting this review-thread on core-libs-dev and build-dev as
this
is a build change, but affects fdlibm which is core-libs.

With JDK-8170153 optimization for fdlibm code has been turned on
for
ppc64 s390 and aarch64. This patch intends to turn it on on all
arches
on Linux. I've not observed any precision issues. Is there a good
reason to not use -O3 -ffp-contract=off everywhere?

Bug:https://bugs.openjdk.java.net/browse/JDK-8210416
webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/

Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
   - Currently running through submit repo.

A simple micro benchmark from JDK-8170153[1] shows these numbers
for
StrictMath:

Function  | before | after
--
sin   | 0m33.382s  | 0m18.731s
cos   | 0m31.562s  | 0m18.796s
tan   | 0m33.657s  | 0m21.093s
atan  | 0m5.714s   | 0m4.902s
log   | 0m6.212s   | 0m4.439s
log10 | 0m7.946s   | 0m5.543s
sqrt  | 0m0.481s   | 0m0.449s
cbrt  | 0m5.295s   | 0m5.214s
tanh  | 0m1.404s   | 0m1.307s
log1p | 0m6.457s   | 0m5.131s
IEEEremainder | 0m10.629s  | 0m6.048s
atan2 | 0m8.037s   | 0m5.668s
hypot | 0m2.171s   | 0m2.147s

Thoughts?

Thanks,
Severin

Re: RFR : [XS] 8209942: [epsilon] range function for EpsilonTLABElasticity causes compiler warning

2018-09-06 Thread Baesken, Matthias 
Hi Erik,   looks like gcc7  and  current clang   already  print  the macro  and 
show it  plus the position of  the error / warning   in it .

See   https://clang.llvm.org/diagnostics.html   Automatic Macro Expansion   
 for an example .

With Visual Studio I could not  find  anything similar ,   I asked our local 
Visual Studio experts for help,  maybe I overlooked something .
  
Best regards, Matthias


> --
> 
> Message: 4
> Date: Wed, 5 Sep 2018 09:57:06 -0700
> From: Erik Joelsson 
> To: "Baesken, Matthias" ,
>   "'hotspot-...@openjdk.java.net'"  d...@openjdk.java.net>,
>   "'build-dev@openjdk.java.net'" 
> Cc: "Simonis, Volker" 
> Subject: Re: RFR : [XS] 8209942: [epsilon] range function for
>   EpsilonTLABElasticity causes compiler warning
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> 
> 
> On 2018-09-05 04:03, Baesken, Matthias wrote:
> > Hello,  when compilingjdk/jdk   on Windows,  (with VS2017 update level
> 15.8 and not disabling warnings as errors )
> > I came across  this  warning   leading to build error :
> >
> > C:/jdk-just-
> clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): error
> C2220: warning treated as error - no 'object' file generated
> > C:/jdk-just-
> clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): warning
> C4305: 'argument': truncation from 'const intx' to 'double'
> >
> > Would have been helpful  to have a compiler flag set  that really   ***shows
> the code***  leading to the warning/error  (because it comes from heavy
> macro expansion).
> >
> Do you know of such a flag? If so we certain would like to add it.
> 
> /Erik
> 
>

Re: RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization

2018-09-06 Thread Severin Gehwolf 
Hi,

On Thu, 2018-09-06 at 07:29 +1000, David Holmes wrote:
> Hi Severin,
> 
> On 6/09/2018 4:36 AM, Severin Gehwolf wrote:
> > Hi,
> > 
> > On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get
> > compiled with -O0. It appears to be for the same (historical?) reason
> > as for fdlibm files in core-libs. JDK-8210416 is an attempt to make
> > this consistent on all Linux arches (as s390x/ppc64/aarch64 already use
> > that) for fdlibm. This patch does the same for the hotspot copies.
> > Compile it with OPT and -ffp-contract=off instead of no optimization at
> > all. Thoughts?
> 
> The code in sharedRuntimeTrig is expected/required to be built the same 
> way as the fdlibm library as it contains the same code. So if it is okay 
> to change the way fdlibm is built then it follows this is okay too. I 
> traced this change to the optimization flags back to 2001 but no details 
> on the exact issue seen with fdlibm.

Right. I should note that ppc64, s390x and aarch64 ports don't have
this optimization turned off as those overrides are in a x86 specific
block. It appears it hasn't caused issues for these ports so far.

Your comment on JDK-8210416 says that it was introduced for an issue on
GCC 1.1.1 i386 back in 1998. Wow ;-)

> Is -ffp-contract=off a gcc-specific flag? If so this should be a gcc 
> conditional not a linux-x86 one.

clang has it (as noted elsewhere), but I don't know which version.
What's the "blessed" clang version for JDK 12?

Thanks,
Severin

> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.01/
> > Bug:https://bugs.openjdk.java.net/browse/JDK-8210425
> > 
> > Testing: - make run-test-tier1 (no new failures).
> >   - Currently running through submit.
> >   - Verified objects get compiled with -O3 -ffp-contract=off in
> > build logs.
> > 
> > Thanks,
> > Severin
> >

RE: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

2018-09-06 Thread Lindenmaier, Goetz 
Yes, that's fine. 

I can sponsor it tomorrow. I'm not in the office today.

Best regards,
  Goetz.

> -Original Message-
> From: Andrew Leonard 
> Sent: Donnerstag, 6. September 2018 12:29
> To: Magnus Ihse Bursie ; Lindenmaier, Goetz
> 
> Cc: 2d-dev <2d-...@openjdk.java.net>; Brian Burkhalter
> ; build-dev ; core-
> libs-dev ; Philip Race
> 
> Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
> zLinux
> 
> Thanks Magnus,
> 
> Hi Goetz, we have agreement from both library owners, so I think we're good
> now?
> Thanks
> Andrew
> 
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leon...@uk.ibm.com
> 
> 
> 
> 
> From:Magnus Ihse Bursie 
> To:Andrew Leonard 
> Cc:Brian Burkhalter , 2d-dev <2d-
> d...@openjdk.java.net>, build-dev , core-libs-dev
> , "Lindenmaier, Goetz"
> , Philip Race 
> Date:04/09/2018 16:41
> Subject:Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors 
> on
> zLinux
> 
> 
> 
> 
> 
> 
> Looks good to me.
> 
> /Magnus
> 
> 4 sep. 2018 kl. 12:11 skrev Andrew Leonard   >:
> 
> Hi Brian/Goetz,
> Yes, that seems sensible. I have created a new webrev with fdlibm compiler
> option disabled, and mediaLib code fixed:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/
> 
> I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3.
> 
> Are we good to go?
> Thanks
> Andrew
> 
> hg export:
> # HG changeset patch
> # User aleonard
> # Date 1536055438 -3600
> #  Tue Sep 04 11:03:58 2018 +0100
> # Node ID c2523f285c503e8f82f1212b38de1cb54093255e
> # Parent  3ee91722550680c18b977f0e00b1013323b5c9ef
> 8209786: JDK12 fails to build on s390x with gcc 7.3
> 
> diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk
> --- a/make/lib/CoreLibraries.gmkTue Sep 04 14:47:55 2018 +0800
> +++ b/make/lib/CoreLibraries.gmkTue Sep 04 11:03:58 2018 +0100
> @@ -68,7 +68,7 @@
>   CFLAGS_linux_ppc64le := -ffp-contract=off, \
>   CFLAGS_linux_s390x := -ffp-contract=off, \
>   CFLAGS_linux_aarch64 := -ffp-contract=off, \
> -  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \
> +  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation array-
> bounds, \
>   DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
>   ARFLAGS := $(ARFLAGS), \
>   OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \
> diff -r 3ee917225506 -r c2523f285c50
> src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
> --- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
> Tue Sep 04 14:47:55 2018 +0800
> +++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
> Tue Sep 04 11:03:58 2018 +0100
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights 
> reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -259,18 +259,18 @@
>   }
> 
> #ifdef _LITTLE_ENDIAN
> -  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
> +  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
> #else
> -  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
> +  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
>   ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ emask);
> 
> #else /* _NO_LONGLONG */
> 
> #ifdef _LITTLE_ENDIAN
> -  mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8);
> +  mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8);
> #else
> -  mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8);
> +  mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
> 
>   ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) |
> (((mlib_u64*)da)[0] &~ emask);
> @@ -395,9 +395,9 @@
>   }
> 
> #ifdef _LITTLE_ENDIAN
> -  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
> +  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
> #else
> -  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
> +  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
>   ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask);
> 
> @@ -413,9 +413,9 @@
>   }
> 
> #ifdef _LITTLE_ENDIAN
> -  emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8);
> +  emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8);
> #else
> -  emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8);
> +  emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8);
> #endif /* _LITTLE_ENDIAN */
>   ((mlib_u64*)da)[0] = (dd

Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

2018-09-06 Thread Andrew Leonard 
Thanks Magnus,

Hi Goetz, we have agreement from both library owners, so I think we're 
good now?
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:   Magnus Ihse Bursie 
To: Andrew Leonard 
Cc: Brian Burkhalter , 2d-dev 
<2d-...@openjdk.java.net>, build-dev , 
core-libs-dev , "Lindenmaier, Goetz" 
, Philip Race 
Date:   04/09/2018 16:41
Subject:Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler 
errors on zLinux



Looks good to me. 

/Magnus

4 sep. 2018 kl. 12:11 skrev Andrew Leonard :

Hi Brian/Goetz, 
Yes, that seems sensible. I have created a new webrev with fdlibm compiler 
option disabled, and mediaLib code fixed: 
http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ 
I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3. 

Are we good to go? 
Thanks 
Andrew 

hg export: 
# HG changeset patch 
# User aleonard 
# Date 1536055438 -3600 
#  Tue Sep 04 11:03:58 2018 +0100 
# Node ID c2523f285c503e8f82f1212b38de1cb54093255e 
# Parent  3ee91722550680c18b977f0e00b1013323b5c9ef 
8209786: JDK12 fails to build on s390x with gcc 7.3 

diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk 
--- a/make/lib/CoreLibraries.gmkTue Sep 04 14:47:55 2018 +0800 
+++ b/make/lib/CoreLibraries.gmkTue Sep 04 11:03:58 2018 +0100 
@@ -68,7 +68,7 @@ 
   CFLAGS_linux_ppc64le := -ffp-contract=off, \ 
   CFLAGS_linux_s390x := -ffp-contract=off, \ 
   CFLAGS_linux_aarch64 := -ffp-contract=off, \ 
-  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \ 
+  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
array-bounds, \ 
   DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ 
   ARFLAGS := $(ARFLAGS), \ 
   OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \ 
diff -r 3ee917225506 -r c2523f285c50 
src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c 
--- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c   
  Tue Sep 04 14:47:55 2018 +0800 
+++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c   
  Tue Sep 04 11:03:58 2018 +0100 
@@ -1,5 +1,5 @@ 
 /* 
- * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. 

+ * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights 
reserved. 
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 
  * 
  * This code is free software; you can redistribute it and/or modify it 
@@ -259,18 +259,18 @@ 
   } 
  
 #ifdef _LITTLE_ENDIAN 
-  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
+  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
 #else 
-  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
+  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
   ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ 
emask); 
  
 #else /* _NO_LONGLONG */ 
  
 #ifdef _LITTLE_ENDIAN 
-  mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 
8); 
+  mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); 
 #else 
-  mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); 
+  mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
  
   ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | 
(((mlib_u64*)da)[0] &~ emask); 
@@ -395,9 +395,9 @@ 
   } 
  
 #ifdef _LITTLE_ENDIAN 
-  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
+  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
 #else 
-  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
+  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
   ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask); 

  
@@ -413,9 +413,9 @@ 
   } 
  
 #ifdef _LITTLE_ENDIAN 
-  emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); 
+  emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); 
 #else 
-  emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); 
+  emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
   ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask); 
  
@@ -565,9 +565,9 @@ 
   } 
  
 #ifdef _LITTLE_ENDIAN 
-  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
+  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
 #else 
-  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
+  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
 #endif /* _LITTLE_ENDIAN */ 
   da[0] = (dd & emask) | (da[0] &~ emask); 
 } 







Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com 




From:Brian Burkhalter  
To:Magnus Ihse Bursie  
Cc:Andrew Leonard ,

Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

2018-09-06 Thread Severin Gehwolf 
Hi Joe,

On Wed, 2018-09-05 at 12:15 -0700, joe darcy wrote:
> On 9/5/2018 6:12 AM, Severin Gehwolf wrote:
> > Hi,
> > 
> > Cross-posting this review-thread on core-libs-dev and build-dev as
> > this
> > is a build change, but affects fdlibm which is core-libs.
> > 
> > With JDK-8170153 optimization for fdlibm code has been turned on
> > for
> > ppc64 s390 and aarch64. This patch intends to turn it on on all
> > arches
> > on Linux. I've not observed any precision issues. Is there a good
> > reason to not use -O3 -ffp-contract=off everywhere?
> > 
> > Bug:https://bugs.openjdk.java.net/browse/JDK-8210416
> > webrev: 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
> > 
> > Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
> >   - Currently running through submit repo.
> > 
> > A simple micro benchmark from JDK-8170153[1] shows these numbers
> > for
> > StrictMath:
> > 
> > Function  | before | after
> > --
> > sin   | 0m33.382s  | 0m18.731s
> > cos   | 0m31.562s  | 0m18.796s
> > tan   | 0m33.657s  | 0m21.093s
> > atan  | 0m5.714s   | 0m4.902s
> > log   | 0m6.212s   | 0m4.439s
> > log10 | 0m7.946s   | 0m5.543s
> > sqrt  | 0m0.481s   | 0m0.449s
> > cbrt  | 0m5.295s   | 0m5.214s
> > tanh  | 0m1.404s   | 0m1.307s
> > log1p | 0m6.457s   | 0m5.131s
> > IEEEremainder | 0m10.629s  | 0m6.048s
> > atan2 | 0m8.037s   | 0m5.668s
> > hypot | 0m2.171s   | 0m2.147s
> > 
> > 
> 
> Note that pow (JDK-8134795), hypot (JDK-7130085), cbrt (JDK-8136799), 
> and exp (JDK-8139688), have been ported to Java as of JDK 9. The sqrt 
> method is commonly handled as an intrinsic.

OK thanks. Since ppc64/s390x/aarch64 uses this already on Linux do you
anticipate the same being applied to x86/x86_64 causing issues (modulo
compiler bugs of course)?

> Testing that was not geared toward finding precision/rounding issues 
> would be unlikely to find them.

Would running the TCK be geared towards precision/rounding issues? I
could ask someone to run the TCK on a test build on x86_64/x86 to find
out.

> I don't see the sources of the microbenchmark in JDK-8170153.

https://github.com/gromero/strictmath/

Thanks,
Severin

Re: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation

2018-09-06 Thread Severin Gehwolf 
Hi David,

On Thu, 2018-09-06 at 07:32 +1000, David Holmes wrote:
> Hi Severin,
> 
> Might as well raise this here too as it's really a build philosophy 
> issue. Shouldn't flags like -ffp-contract=off (and the existing AIX 
> -qfloat=nomaf) be toolchain specific rather than platform specific?

Looks like Clang has -ffp-contract:
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-ffp-contract

Is there any other (supported) toolchain other than gcc and clang on
linux? As for AIX I suppose there is only on supported toolchain?

Thanks,
Severin

> Thanks,
> David
> 
> On 5/09/2018 11:12 PM, Severin Gehwolf wrote:
> > Hi,
> > 
> > Cross-posting this review-thread on core-libs-dev and build-dev as
> > this
> > is a build change, but affects fdlibm which is core-libs.
> > 
> > With JDK-8170153 optimization for fdlibm code has been turned on
> > for
> > ppc64 s390 and aarch64. This patch intends to turn it on on all
> > arches
> > on Linux. I've not observed any precision issues. Is there a good
> > reason to not use -O3 -ffp-contract=off everywhere?
> > 
> > Bug:https://bugs.openjdk.java.net/browse/JDK-8210416
> > webrev: 
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/webrev.01/
> > 
> > Testing: - java/lang/Math, java/lang/StrictMath tests (all pass).
> >   - Currently running through submit repo.
> > 
> > A simple micro benchmark from JDK-8170153[1] shows these numbers
> > for
> > StrictMath:
> > 
> > Function  | before | after
> > --
> > sin   | 0m33.382s  | 0m18.731s
> > cos   | 0m31.562s  | 0m18.796s
> > tan   | 0m33.657s  | 0m21.093s
> > atan  | 0m5.714s   | 0m4.902s
> > log   | 0m6.212s   | 0m4.439s
> > log10 | 0m7.946s   | 0m5.543s
> > sqrt  | 0m0.481s   | 0m0.449s
> > cbrt  | 0m5.295s   | 0m5.214s
> > tanh  | 0m1.404s   | 0m1.307s
> > log1p | 0m6.457s   | 0m5.131s
> > IEEEremainder | 0m10.629s  | 0m6.048s
> > atan2 | 0m8.037s   | 0m5.668s
> > hypot | 0m2.171s   | 0m2.147s
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> >

Request for approval: 8210423: Backport of 8034788 breaks GCC version detection

2018-09-06 Thread Andrew Haley 
The JDK8u backport of 8034788 changed the variable name CXX_VERSION
(in configure) to CXX_VERSION_NUMBER. Unfortunately this was not done
consistently, and as a result the version number check for GCC is
broken. As a result of that brokenness, HotSpot built on all GCC
versions >=6 is unstable.

Intriguingly, the comments aroud te affected code are correct, and
refer to CXX_VERSION_NUMBER, but the actual variable name is wrong.

http://cr.openjdk.java.net/~aph/8210423/

OK?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671