On 11/21/16 4:27 PM, Gustavo Romero wrote:
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 contro
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
Hello,
On 11/21/2016 4:34 PM, Gustavo Romero wrote:
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 a
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
Ah, ok, so this is fine.
Best regards,
Goetz.
> -Original Message-
> From: Erik Joelsson [mailto:[email protected]]
> Sent: Montag, 21. November 2016 14:27
> To: Lindenmaier, Goetz ; Vladimir Kozlov
> ; build-dev ;
> core-libs-dev ; hotspot-dev developers
>
> Subject: Re: RFR: J
Hello Goetz,
Thanks for trying this out. Note that the ergo* files were removed in
JDK-8169001 which is currently in jdk9/dev but not yet in hs.
/Erik
On 2016-11-21 14:10, Lindenmaier, Goetz wrote:
Hi,
linuxx86_64 has the same issue. I tested it with the jdk9/hs repo:
jdk/src/java.base/u
Hi,
linuxx86_64 has the same issue. I tested it with the jdk9/hs repo:
jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function
ServerClassMachineImpl:
jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected )
before LIBARCHNAME
Best regards,
Goetz
> -Original Mes
Hi,
we appreciate this change a lot, and also if /server would go away.
I built and tested it on linuxppcle, aixppc and linuxs390.
There is still a place that refers to a removed variables
and breaks the build:
jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME
You can probably just rep
On 18/11/16 15:30, Erik Joelsson wrote:
Please review this change which removes the $ARCH sub directory in the
lib directory of the runtime images, which is an outstanding issue from
the new runtime images. Most of the changes are in the build, but there
are some in hotspot and launcher source.
The current javadoc generation first creates the coredocs Javadoc, and
after that all the remaining javadoc instances.
This dependency is not really needed, all that is required is that the
remaining javadoc instances gets a proper pointer to a package-list file
for coredocs. Fixing that will
12 matches
Mail list logo
