Hello,
On 9/12/2018 1:16 AM, Severin Gehwolf wrote:
On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
But I don't understand why the optimization setting is being tied to the
availability of the -ffp-contract flag?
In configure we perform a check for gcc or clang whether that flag is
Correction ...
On 13/09/2018 8:31 AM, David Holmes wrote:
On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
But I don't understand why the optimization setting is being tied to the
availability of the -ffp-contract flag?
In configure we
On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
But I don't understand why the optimization setting is being tied to the
availability of the -ffp-contract flag?
In configure we perform a check for gcc or clang whether that flag is
Hi Leslie,
The problem really lies in the OpenJDK code, as it is attempting to
write to a const object. If this seems to work with certain compiler(s)
and optimization settings, it is just luck. :-)
Here is a reduced example, which shows the issue:
Hi Leslie,
This is likely the same problem as was reported in
https://bugs.freebsd.org/225054#c8, and fixed by the following patch:
https://svnweb.freebsd.org/ports/head/java/openjdk8/files/patch-hotspot_src_share_vm_services_memTracker.cpp?view=markup=459368
Can you please try that out, and
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"
wrote:
Looks good.
/Erik
On 2018-09-12 10:33, naoto.s...@oracle.com wrote:
Hi Magnus, Erik,
Thank you for your comments. I updated the webrev according to your
suggestions:
http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
As to the duplicated "common" in the dependency, yes that's a
Hi Magnus, Erik,
Thank you for your comments. I updated the webrev according to your
suggestions:
http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
As to the duplicated "common" in the dependency, yes that's a separate
issue. Since it's obvious, I included the fix with this changeset (it
Hello,
I very much doubt it was included with the new build system. We were
extremely careful to use the exact same flags then, and did binary
comparisons of all object files to verify equal builds.
Tracing back, it was caused (probably unintentionally) by this change:
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:
On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie
wrote:
> On 2018-09-05 20:59, Martin Buchholz wrote:
>
> So ... Magnus, are you happy with the current state of the proposed patch?
>
> I'm sorry Martin, but I can't figure out what the current state is. I tried
> backtracking the discussion but
Hi,
Does anybody know why vmStructs.cpp gets an override in
JvmOverrideFiles.gmk:
$ grep -C3 -n vmStructs.cpp make/hotspot/lib/JvmOverrideFiles.gmk
30-# status for individual files on specific platforms.
31-
32-ifeq ($(TOOLCHAIN_TYPE), gcc)
33: BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS :=
On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
On 2018-09-10 23:34, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209167
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
Some
Hi Andrew,
On 09/12/2018 12:51 AM, Gustavo Romero wrote:
Maybe Andrew can enlight us.
I was not sure if 'enlight us' was the correct form here, so I did some search
and I found with horror today that 'enlighten us' can also be considered an
insult (!?).
That's really not the case here. So
Probably should also backport the followup RFE:
https://bugs.openjdk.java.net/browse/JDK-8206183
Thanks,
-Zhengyu
On 09/11/2018 10:58 PM, David Holmes wrote:
Or to be a little less obscure, this is a known issue and you should
look into backporting:
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
On 2018-09-12 13:49, Jan Lahoda wrote:
Hi,
I've updated the data patch to include the recently added
java.net.http.HttpConnectTimeoutException (see JDK-8209187):
http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.01/
The code patch remains unchanged from the last round:
Hi,
I've updated the data patch to include the recently added
java.net.http.HttpConnectTimeoutException (see JDK-8209187):
http://cr.openjdk.java.net/~jlahoda/8207954/webrev.data.01/
The code patch remains unchanged from the last round:
On 2018-09-10 15:36, Robin Westberg wrote:
Hi all,
Please review the following change that adds support for generating compile_commands.json
as a top-level make target. This is a popular format for describing how to compile object
files for a project, and is defined in [1]. This file can be
On 2018-09-05 20:59, Martin Buchholz wrote:
So ... Magnus, are you happy with the current state of the proposed patch?
I'm sorry Martin, but I can't figure out what the current state is. I
tried backtracking the discussion but failed. :( Can you please repost
the currently proposed patch?
On 2018-09-11 18:14, Severin Gehwolf wrote:
Hi Erik,
Thanks for the review!
On Tue, 2018-09-11 at 08:57 -0700, Erik Joelsson wrote:
Hello Severin,
Even if using the macro, I still think you need to add a condition on
the compiler types where the switch can be reasonably expected to exist.
On 2018-09-12 12:19, Magnus Ihse Bursie wrote:
On 2018-09-10 23:34, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209167
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
Oh,
On 2018-09-11 20:39, Erik Joelsson wrote:
Hello,
I do agree with your points.
http://cr.openjdk.java.net/~erikj/8210519/webrev.02/
Looks good to me.
/Magnus
On 2018-09-11 11:32, Mikael Vidstedt wrote:
Looks good, thanks for fixing.
Arguably the ":((hg)|(git)):[a-z0-9]*\\+?” string
On 2018-09-10 23:34, Naoto Sato wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8209167
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
Some comments:
In make/copy/Copy-java.base.gmk:
+ifneq
On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
> But I don't understand why the optimization setting is being tied to the
> availability of the -ffp-contract flag?
In configure we perform a check for gcc or clang whether that flag is
supported. If it is, it would be non-empty exactly
Hi Severin,
On 12/09/2018 5:48 PM, Severin Gehwolf wrote:
Hi David,
On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
Hi Severin,
Sorry I'm a bit confused now.
Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
HIGH. But now it will be LOW due to:
45 ifneq
On Tue, 2018-09-11 at 10:30 -0700, Erik Joelsson wrote:
> Looks good, thanks!
Thanks for the review, Erik.
We've ran JCK 11 on this patch which passed on our end. I'll wait a few
more days whether there are objections and then push it.
Thanks,
Severin
> /Erik
>
>
> On 2018-09-11 09:14,
Hi David,
On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
> Hi Severin,
>
> Sorry I'm a bit confused now.
>
> Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
> HIGH. But now it will be LOW due to:
>
>45 ifneq ($(FDLIBM_CFLAGS), )
>46
28 matches
Mail list logo
