Re: [11] Review Request: 8200146 Remove the appletviewer launcher

On 2018-03-31 00:52, Sergey Bylokhov wrote: Hello. Please review fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8200146 Webrev can be found at: http://cr.openjdk.java.net/~serb/8200146/webrev.00 Build changes look good. /Magnus CSR:

Re: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests

On 2018-03-31 09:30, David Holmes wrote: Hi Misha. This all seems okay. On 30/03/2018 12:41 PM, Mikhailo Seledtsov wrote: While testing I discovered build errors on Mac and Solaris. The following statement " BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exesigtest := -ljvm" was added to a Linux-only

Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c

I also advocate the source code fix, as Make isn't meant to use the sort of logic required to properly analyse the toolchain version string. e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, and Make doesn't seem to do substring stuff unless you mess around with shells.

Re: RFR(XXS) : 8200538 : cl : Command line warning D9014 : invalid value '2220' for '/wd'

On 2018-03-31 00:10, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev/8200538/webrev.00/ 1 line changed: 0 ins; 0 del; 1 mod; Hi all, could you please review this one-liner change which removes C2220 from disabled warning on windows? C2220 is "warning treated as error" compiler

Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c

On 2018-03-27 18:44, Phil Race wrote: As I said I prefer the make file change, since this is a change to an upstream library. Newtons fourth law: For every reviewer, there's an equal and opposite reviewer. :) Here I am, advocating a source code fix. As Thomas says, the compiler complaint

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

(pruning cc-list somewhat) On 2018-03-29 08:16, Martin Buchholz wrote: That surprises me. I'm quite certain that javah (or rather, java -h nowadays) generate header files with JNIEXPORT and JNICALL. As you can see in the jni.h and jni_md.h files, JNIEXPORT equals

RFR: JDK-8200267 a.out created at top dir by Solaris build

There's an unwanted a.out in the top directory when building with Solaris. This one was actually a bit tricky to hunt down. It is created by ld when extracting the version information, but only when the output of ld is piped to head. I'm guessing this has something to do with how Solaris

Re: a.out left in root directory when configuring --with-toolchain-type=clang

Actually, the clang issue is different. The fix for JDK-8200267 is solstudio only. Martin: I cannot reproduce the behaviour with "bash configure --with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin". No a.out file for me. Is this repeatable? Are you sure you didn't

Re: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

On 2018-03-29 14:51, Thomas Stüfe wrote: Hi Magnus, On Thu, Mar 29, 2018 at 8:47 AM, Thomas Stüfe > wrote: On Thu, Mar 29, 2018 at 12:37 AM, Magnus Ihse Bursie

Re: a.out left in root directory when configuring --with-toolchain-type=clang

It's some kind of weird race. $ rm -f a.out; bash configure --with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin >&/dev/null; ls -l a.out; file a.out bash configure --with-toolchain-type=clang >&/dev/null 5.04s user 3.81s system 94% cpu 9.323 total -rw-r--r-- 1 martin martin

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

On Tue, Apr 3, 2018 at 6:04 AM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > (pruning cc-list somewhat) > > On 2018-03-29 08:16, Martin Buchholz wrote: > > That surprises me. I'm quite certain that javah (or rather, java -h > nowadays) generate header files with JNIEXPORT and

Re: RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle

On 2018-04-03 20:14, Erik Joelsson wrote: This patch changes the default devkit used to produce builds for Linux x64 at Oracle. The new devkit is based on GCC 7.3.0. Woho! :) The future is here. What a leap, 4.9.2 -> 7.3.0. Webrev: http://cr.openjdk.java.net/~erikj/8200375/webrev.01/ Looks

Re: RFR: JDK-8200267 a.out created at top dir by Solaris build

Looks good! /Erik On 2018-04-03 06:11, Magnus Ihse Bursie wrote: There's an unwanted a.out in the top directory when building with Solaris. This one was actually a bit tricky to hunt down. It is created by ld when extracting the version information, but only when the output of ld is piped

Re: RFR(M): 8200126: [TESTBUG] Open source VM runtime signal tests

David, Christian, Magnus, Thank you for review. Misha On 04/03/2018 05:15 AM, Magnus Ihse Bursie wrote: On 2018-03-31 09:30, David Holmes wrote: Hi Misha. This all seems okay. On 30/03/2018 12:41 PM, Mikhailo Seledtsov wrote: While testing I discovered build errors on Mac and Solaris.

RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle

This patch changes the default devkit used to produce builds for Linux x64 at Oracle. The new devkit is based on GCC 7.3.0. Webrev: http://cr.openjdk.java.net/~erikj/8200375/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8200375 /Erik

Re: space.inline.hpp build failure

Hello Peter, Forwarding this to hotspot-dev as it's an issue with hotspot. /Erik On 2018-03-29 23:36, Peter Johnson wrote: When cross compiling either 9 or 10 to ARM with gcc 5.5.0, I get the following linker error: /tmp/cc7TKVtK.ltrans2.ltrans.o: In function

Re: a.out left in root directory when configuring --with-toolchain-type=clang

On 2018-04-03 19:55, Martin Buchholz wrote: It's some kind of weird race. Weird. I can't help you out here, since I cannot reproduce. I can tell you what I did to find the strange a.out file for solaris -- I opened one terminal with a "while true; do ls -l a.out; done", and one running

Re: RFR: JDK-8200375: Change to GCC 7.3.0 for building Linux at Oracle

Erik: On 04/03/18 12:38, Magnus Ihse Bursie wrote: On 2018-04-03 20:14, Erik Joelsson wrote: This patch changes the default devkit used to produce builds for Linux x64 at Oracle. The new devkit is based on GCC 7.3.0. Woho! :) The future is here. What a leap, 4.9.2 -> 7.3.0. Indeed.

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

Here's an updated webrev that uses the same pattern as for native shared libraries to hide non-exported symbols, for executables as well. I hope you're happy now :-) WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.02 I know there's a bit of redundancy

Re: RFR: JDK-8200358 Remove mapfiles for JDK executables

Looks good to me at least. Exporting symbols from executables seems wrong so applying hidden as default seems good to me. /Erik On 2018-04-03 13:42, Magnus Ihse Bursie wrote: Here's an updated webrev that uses the same pattern as for native shared libraries to hide non-exported symbols, for

RFR: JDK-8200658 Fix incremental builds of hotspot on solaris

On solaris, jvmciCompilerToVMInit.cpp is always recompiling when building incrementally. The reason is a combination of broken code in NativeCompilation.gmk and special options that trigger this on solaris. (OPTIMIZATION := NONE, which caused OPT_C[XX]FLAGS to be empty) Bug:

Re: RFR: JDK-8200658 Fix incremental builds of hotspot on solaris

Looks good. /Erik On 2018-04-03 13:25, Magnus Ihse Bursie wrote: On solaris, jvmciCompilerToVMInit.cpp is always recompiling when building incrementally. The reason is a combination of broken code in NativeCompilation.gmk and special options that trigger this on solaris. (OPTIMIZATION :=