RFR: JDK-8205055: Fix compilation optimization errors with new Solaris toolchain
Locally tested the fix below and via mach5 jobs. The ~50 failed tests all completed successfully. It'd be good for Erik to repeat his full testing with this patch included in case it blocked other issues from being observed. This fix can be integrated after the sync from jdk/client. Issue: https://bugs.openjdk.java.net/browse/JDK-8205055 Proposed fix: diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk b/make/hotspot/lib/JvmOverrideFiles.gmk --- a/make/hotspot/lib/JvmOverrideFiles.gmk +++ b/make/hotspot/lib/JvmOverrideFiles.gmk @@ -74,6 +74,8 @@ else ifeq ($(OPENJDK_TARGET_OS), solaris) ifneq ($(DEBUG_LEVEL), slowdebug) + # dev studio 12.6 workaround + BUILD_LIBJVM_arguments.cpp_OPTIMIZATION := LOW
Re: RFR: JDK-8205055: Fix compilation optimization errors with new Solaris toolchain
On 2018-06-15 01:26, gary.ad...@oracle.com wrote: Locally tested the fix below and via mach5 jobs. The ~50 failed tests all completed successfully. It'd be good for Erik to repeat his full testing with this patch included in case it blocked other issues from being observed. This fix can be integrated after the sync from jdk/client. Issue: https://bugs.openjdk.java.net/browse/JDK-8205055 Proposed fix: diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk b/make/hotspot/lib/JvmOverrideFiles.gmk --- a/make/hotspot/lib/JvmOverrideFiles.gmk +++ b/make/hotspot/lib/JvmOverrideFiles.gmk @@ -74,6 +74,8 @@ else ifeq ($(OPENJDK_TARGET_OS), solaris) ifneq ($(DEBUG_LEVEL), slowdebug) + # dev studio 12.6 workaround + BUILD_LIBJVM_arguments.cpp_OPTIMIZATION := LOW The if should test ifeq ($(TOOLCHAIN_TYPE), solstudio) since this is a compiler issue, not an OS issue. Ideally, it should also test if using version 12.6, but unfortunately there's currently no elegant way of expressing that in the makefiles, so I'm OK with the workaround of just having a comment. I assume, from the name and a quick glance at the file, that the contents makes it unlikely that a lowevered optimization level wouldprovoke a performance regression in pre-12.6 solstudio compilations. Still, it would be nice if you are able to drill down the issue to figure out exactly why a higher optimization level causes this file to be incorrectly compiled. It might be code in hotspot with undefined behavior, or it might be bugs in solstudio. In any case, it should be addressed. As an initial fix to allow compilation to proceed, this is fine, though. /Magnus
Re: RFR: JDK-8205055: Fix compilation optimization errors with new Solaris toolchain
Hello, On 2018-06-15 05:44, Magnus Ihse Bursie wrote: On 2018-06-15 01:26, gary.ad...@oracle.com wrote: Locally tested the fix below and via mach5 jobs. The ~50 failed tests all completed successfully. It'd be good for Erik to repeat his full testing with this patch included in case it blocked other issues from being observed. This fix can be integrated after the sync from jdk/client. Issue: https://bugs.openjdk.java.net/browse/JDK-8205055 Proposed fix: diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk b/make/hotspot/lib/JvmOverrideFiles.gmk --- a/make/hotspot/lib/JvmOverrideFiles.gmk +++ b/make/hotspot/lib/JvmOverrideFiles.gmk @@ -74,6 +74,8 @@ else ifeq ($(OPENJDK_TARGET_OS), solaris) ifneq ($(DEBUG_LEVEL), slowdebug) + # dev studio 12.6 workaround + BUILD_LIBJVM_arguments.cpp_OPTIMIZATION := LOW The if should test ifeq ($(TOOLCHAIN_TYPE), solstudio) since this is a compiler issue, not an OS issue. Ideally, it should also test if using version 12.6, but unfortunately there's currently no elegant way of expressing that in the makefiles, so I'm OK with the workaround of just having a comment. I assume, from the name and a quick glance at the file, that the contents makes it unlikely that a lowevered optimization level wouldprovoke a performance regression in pre-12.6 solstudio compilations. Still, it would be nice if you are able to drill down the issue to figure out exactly why a higher optimization level causes this file to be incorrectly compiled. It might be code in hotspot with undefined behavior, or it might be bugs in solstudio. In any case, it should be addressed. As an initial fix to allow compilation to proceed, this is fine, though. I have run more testing using this patch and it does look like it works pretty well with just this change. Nothing sticks out. I agree with Magnus that it needs a TOOLCHAIN_TYPE check. Will you file a followup for investigating what actually goes wrong? /Erik
