8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization
erik.joelsson at oracle.com
Wed Sep 12 17:02:06 UTC 2018
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.
On 2018-09-12 05:44, Severin Gehwolf wrote:
> Updated webrev since fdlibm build change seems to have settled:
> 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?
> 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.
>> On 08.09.18, 11:26, "hotspot-dev on behalf of Andrew Haley" <hotspot-dev-bounces at openjdk.java.net on behalf of aph at 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
More information about the hotspot-dev