Hello Severin,
In configure, we now set FDLIBM_CFLAGS based on toolchain type and
capabilities. In JvmOverrideFiles.gmk, the use of it is still
conditional on Linux. I don't think it should be. We already have the
conditionals we need.
/Erik
On 2018-09-12 05:44, Severin Gehwolf wrote:
Hi,
Updated webrev since fdlibm build change seems to have settled:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.02/
Optimization is being done at level -O2 (CXX_O_FLAG_NORM) with
-ffp-contract=off when the toolchain (gcc/clang at this point)
supports it. Otherwise no optimization will be done. Those overrides
are no longer in an x86 specific block. Thus, ppc64, aarch64, s390x
will get correct settings too.
How does this look?
Thanks,
Severin
On Wed, 2018-09-12 at 07:16 +0000, Schmidt, Lutz wrote:
I totally agree with Andrew's statement. FP calculations should be
evaluated as the programmer wrote them down. All fiddling around with
sequence or rounding is evil. You lose reproducibility of results.
Regards,
Lutz
On 08.09.18, 11:26, "hotspot-dev on behalf of Andrew Haley"
<hotspot-dev-boun...@openjdk.java.net on behalf of a...@redhat.com> wrote:
On 09/06/2018 03:32 PM, Severin Gehwolf wrote:
> 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.
That's just dumb luck. We really should turn off the merging of FP
operations on all platforms.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
