[8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian)

Volker Simonis volker.simonis at gmail.com
Wed Dec 28 08:32:25 UTC 2016

On Tue, Dec 27, 2016 at 11:30 PM, David Holmes <david.holmes at oracle.com> wrote:
> Hi Volker,
> As this is a build change I have added build-dev.
> The change looks fine to me.

Thanks for reviewing!

> Aside: More generally it would be nice if there was a simple way to record
> minimum compiler versions necessary for a given flag/option.

Yes, I first wanted to do this compiler-version dependent.
Unfortunately that would have been much more complex because I don't
have access to the compiler version in CoreLibraries.gmk and I didn't
wanted to start it for legacy code which is not needed in jdk9 anyway.


> Thanks,
> David
> On 28/12/2016 3:17 AM, Volker Simonis wrote:
>> Hi,
>> can I please have a review and approval for pushing the following
>> small, ppc64-only fix to jdk8u-dev:
>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/
>> https://bugs.openjdk.java.net/browse/JDK-8172053
>> The problem is that the recent downport of  "8170153:
>> PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized
>> compilation" breaks the build of jdk8u with the original gcc 4.3 on
>> linux/ppc64. We should however ensure, that an update-release will not
>> break the original tool chain used for a released version of Java.
>> Notice, that this change won't go to jdk9 because it only fixes an
>> issue caused by the downport of another fix to jdk8u which doesn't
>> exist in jdk9.
>> JDK-8170153 increased the optimization level for the compilation of
>> fdlibm on both linux/ppc64 and linux/ppc64le. This only worked by
>> using the option '-ffp-contract=off' which guaranteed correct IEEE
>> floating point behavior.
>> Unfortunately, '-ffp-contract' is only available since gcc 4.6. For
>> ppc64le that's no problem since ppc64le support only appeared in gcc
>> 4.8.3. But on ppc64 (big endian) we traditionally compiled with gcc
>> 4.3 which only knows '-mno-fused-madd'. However, that's still not
>> enough to get the float computations right - we additionally have to
>> supply '-fno-strict-aliasing'.
>> I've tested the new configuration (i.e. '-mno-fused-madd
>> -fno-strict-aliasing') with the corresponding jtreg and JCK tests and
>> couldn't find any issue.
>> Thank you and best regards,
>> Volker

More information about the build-dev mailing list