Hi David,
On 03/25/2019 09:11 PM, David Holmes wrote:
Looks good Gustavo.
Thanks a lot for the quick review.
Pushed to jdk/jdk since it's a trivial change.
Best regards,
Gustavo
Hi,
Could the following trivial change be reviewed, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8221434
webrev : http://cr.openjdk.java.net/~gromero/8221434/v1/
Thank you and best regards,
Gustavo
y, as Goetz is also fine with either option, I'm fine with what
you and Andrew decide as the best option.
Thanks bearing with the discussion on ppc64.
Best regards,
Gustavo
Best regards,
Goetz.
-Original Message-
From: core-libs-dev On Behalf
Of Gustavo Romero
Sent: Freitag, 14.
Hello Severin,
On 09/12/2018 04:48 AM, 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 (
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 rea
Hi Severin,
On 09/11/2018 09:02 AM, Severin Gehwolf wrote:
Micro-benchmark results from running [1] for x86_64 and ppc64le are
here (-O2 is sufficient it seems):
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210416/microbenchmarks_results/
More thoughts?
Thanks a lot for checking it on P
Hi Severin,
On 09/10/2018 06:27 AM, Severin Gehwolf wrote:
On Mon, 2018-09-10 at 10:05 +0100, Andrew Haley wrote:
On 09/05/2018 02:12 PM, Severin Gehwolf wrote:
Is there a good
reason to not use -O3 -ffp-contract=off everywhere?
Is there a good reason to use -O3 rather than -O2?
Not sure.
Hello,
On 09/05/2018 04:15 PM, joe darcy wrote:
Hello,
On 9/5/2018 6:12 AM, Severin Gehwolf wrote:
Hi,
Cross-posting this review-thread on core-libs-dev and build-dev as this
is a build change, but affects fdlibm which is core-libs.
With JDK-8170153 optimization for fdlibm code has been tur
Hi,
On 08/21/2018 08:00 PM, David Holmes wrote:
Hi,
You need to search further up the build log to try and find the actual error
that occurred when building hotspot.
Run "make hotspot" and it should be easier to see.
In addition to David's suggestion you can also add before the command
LOG
Hi Erik, Volker, Andrew
On 29-11-2016 16:15, Andrew Haley wrote:
> On 29/11/16 18:06, Volker Simonis wrote:
>> @Andrew: are you fine with Gustavos latest version of the change?
>
> Sure. The StrictMath versions all seem to give the same results.
>
> Andrew.
>
Thanks for reviewing the change!
Hi Andrew,
On 29-11-2016 13:35, Andrew Haley wrote:
> On 29/11/16 09:41, Volker Simonis wrote:
>> Thanks Gustavo,
>>
>> the change looks good.
>>
>> So now we're just waiting for another review from somebody of the aarch64
>> folks.
>> Once we have that and the fc-request is approved I'll push th
Hi all,
I'm re-sending due to JDK title update to include s390x and aarch64 archs.
Could the following webrev be reviewed, please?
webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/
webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/
bug:https://bugs.openjdk.java.net
Hi Volker,
On 25-11-2016 14:32, Volker Simonis wrote:
> On Fri, Nov 25, 2016 at 3:51 PM, Andrew Haley wrote:
>> On 22/11/16 09:57, Andrew Haley wrote:
>>> On 22/11/16 00:41, Gustavo Romero wrote:
>>>> Do you know if the gap between Math and StrictMath is also huge o
Hi Volker,
Sorry for not replying earlier, it was day-off on Friday here...
On 25-11-2016 11:32, Volker Simonis wrote:
> Hi Gustavo,
>
> we've realized that we have exactly the same problem on Linux/s390 so
> I hope you don't mind that I've updated the bug and the webrev to also
> include the fi
Hi Erik,
On 23-11-2016 12:29, Erik Joelsson wrote:
> Build changes look ok.
>
> In CoreLibraries.gmk, I think it would have been ok to keep the conditional
> checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too.
Thanks a lot for reviewing the change.
Regards,
Gustavo
Hi Martin,
On 23-11-2016 12:38, Doerr, Martin wrote:
> Hi Gustavo,
>
> thanks for providing the webrevs.
>
> I have ran the StrictMath jck tests which fail when building with -O3 and
> without -ffp-contract=off:
> FailedTests:
> api/java_lang/StrictMath/desc.html#acos
> javasoft.sqe.tests.api.
Hi Volker,
On 23-11-2016 12:05, Volker Simonis wrote:
> thanks a lot for tracking this down!
Happy to contribute :)
> The change looks good and I a can sponsor it once you get another
> review from the build group and the FC Extension Request was approved.
Thanks a lot for sponsoring it!
> I
Hi,
Could the following change be reviewed, please?
webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/
webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/
bug:https://bugs.openjdk.java.net/browse/JDK-8170153
It enables fdlibm optimization on Linux PPC64 LE & BE and hence s
Hi Derek,
On 17-11-2016 20:47, White, Derek wrote:
> Hi Joe,
>
> Although neither a floating point expert (as I think I've proven to you over
> the years), or a gcc expert, I checked with our in-house gcc expert and got
> this following answer:
>
> "Yes using -fno-strict-aliasing fixes t
Hi Chris,
On 17-11-2016 19:48, Chris Plummer wrote:
>> The fdlibm code relies on aliasing a two-element array of int with a double
>> to do bit-level reads and writes of floating-point values. As I understand
>> it, the C spec allows compilers to assume
>> values of different types don't overlap
Hi Joe,
On 17-11-2016 19:33, joe darcy wrote:
Currently, optimization for building fdlibm is disabled, except for the
"solaris" OS target [1].
>>> The reason for that is because historically the Solaris compilers have had
>>> sufficient discipline and control regarding floating-point se
Hi Joe,
Thanks a lot for your valuable comments.
On 17-11-2016 15:35, joe darcy wrote:
>> Currently, optimization for building fdlibm is disabled, except for the
>> "solaris" OS target [1].
>
> The reason for that is because historically the Solaris compilers have had
> sufficient discipline an
Hi Erik,
On 17-11-2016 07:17, Erik Joelsson wrote:
> Overall this looks reasonable to me. However, if we want to introduce a new
> possible tuple for specifying compilation flags to SetupNativeCompilation, we
> (the build team) would prefer if we used
> OPENJDK_TARGET_CPU instead of OPENJDK_TARG
Hi David,
On 17-11-2016 00:31, David Holmes wrote:
> Adding in build-dev as they need to scrutinize all build changes.
Thanks a lot.
Regards,
Gustavo
$$(name)), \
> OPTIMIZATION := LOW, \
> )) \
> $$(eval $1 += $$(BUILD_TEST_$$(name)) ) \
>
> /Erik
>
> On 2016-08-17 16:56, Gustavo Romero wrote:
>> Hi Erik,
>>
>> I applied your change:
>>
>> diff -r 397565766eb4 make/test/JtregN
= -ljvm -lpthread
>
> should be:
>
> BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exeinvoke := -ljvm -lpthread
>
> Could someone who is able to repro try this?
>
> /Erik
>
> On 2016-08-17 16:15, Gustavo Romero wrote:
>> Hi David,
>>
>> On 17-08-2016 00:38, Dav
Sorry, again: (reading from left to right the link command).
Regards,
Gustavo
On 17-08-2016 11:15, Gustavo Romero wrote:
> Hi David,
>
> On 17-08-2016 00:38, David Holmes wrote:
>> On 16/08/2016 8:41 AM, Gustavo Romero wrote:
>>> On Ubuntu 16.04 PPC64 LE replacing
Hi David,
On 17-08-2016 00:38, David Holmes wrote:
> On 16/08/2016 8:41 AM, Gustavo Romero wrote:
>> On Ubuntu 16.04 PPC64 LE replacing -lpthread by -pthread in
>> ./hotspot/make/test/JtregNative.gmk:82 solves the issue on pthread_* symbols
>> and
>> placing -ljvm
Hi,
I observed the same issue on Ubuntu 16.04 but not on RHEL 7.2.
RHEL 7.2:
https://paste.fedoraproject.org/409005/raw/
Ubuntu 16.04:
https://paste.fedoraproject.org/409004/raw/
I checked on PPC64 LE arch (Ubuntu 16.04 and RHEL 7.2, logs above). It fails
also
on Ubuntu 16.04 x64 (but I could
29 matches
Mail list logo
