Hi Volker,
As this is a build change I have added build-dev.
The change looks fine to me.
Aside: More generally it would be nice if there was a simple way to
record minimum compiler versions necessary for a given flag/option.
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
