Re: compiling openJdk 11 on windows 7 32bits fail
I just tried --disable-warnings-as-errors, and JDK 11 64bits as a bootjdk, but I get a lots of errors, and it refuse to build, like this: c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(229): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(250): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(289): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(312): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(333): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(372): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(437): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' c:/cygwin64/home/franc/java/jdk11/src/hotspot/share/code/codeBlob.cpp(541): error C2956: sized deallocation function 'operator delete(void*, size_t)' would be chosen as placement deallocation function. predefined C++ types (compiler internal)(44): note: see declaration of 'operator delete' El mié., 6 de feb. de 2019 a la(s) 16:15, Erik Joelsson ( erik.joels...@oracle.com) escribió: > If you are running into warnings treated as errors, please try > configuring with --disable-warnings-as-errors. That is often needed on > less tested platforms. > > Note that as long as you run the build on a 64 bit system, you can use a > 64 bit bootjdk to build a 32 bit JDK. > > /Erik > > On 2019-02-06 11:07, Franco Gastón Pellegrini wrote: > > Can this be fixed before JDK 12? I will not able to compile java 12 > 32bits > > because I will not have java 11 32bits as a boot-jdk. > > > > El sáb., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( > > david.hol...@oracle.com) escribió: > > > >> On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: > >>> On 2018-11-23 08:35, Franco Gastón Pellegrini wrote: > Using the same command as before, and then using > make CONF=windows-x86-normal-client-fastdebug clean; > make CONF=windows-x86-normal-client-fastdebug; > > I get warnings as error, and cannot compile. The output is (and I > attached the logs): > > $ make CONF=windows-x86-normal-client-fastdebug; > Building target 'default (exploded-image)' in configuration > 'windows-x86-normal-client-fastdebug' > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > Compiling 2 files for BUILD_JVMTI_TOOLS > Compiling 1 files for BUILD_JFR_TOOLS > Compiling 12 properties into resource bundles for jdk.jdeps > Compiling 7 properties into resource bundles for jdk.jshell > Parsing 2 properties into enum-like class for jdk.compiler > Compiling 19 properties into resource bundles for jdk.compiler > Compiling 13 properties into resource bundles for jdk.javadoc > Compiling 117 files for BUILD_java.compiler.interim > Compiling 394 files for BUILD_jdk.compiler.interim > Creating support/modules_libs/java.base/client/jvm.dll from 746 > file(s) > Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s) > Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 > file(s) > Compiling 299 files for BUILD_jdk.javadoc.interim > Compiling 162 files for BUILD_TOOLS_JDK > Compiling 188 files for BUILD_jdk.rmic.interim > Note: Some input files use or override a deprecated API. > Note: Recompile with
Re: compiling openJdk 11 on windows 7 32bits fail
Thanks for the tip! El mié., 6 de feb. de 2019 a la(s) 16:15, Erik Joelsson ( erik.joels...@oracle.com) escribió: > If you are running into warnings treated as errors, please try > configuring with --disable-warnings-as-errors. That is often needed on > less tested platforms. > > Note that as long as you run the build on a 64 bit system, you can use a > 64 bit bootjdk to build a 32 bit JDK. > > /Erik > > On 2019-02-06 11:07, Franco Gastón Pellegrini wrote: > > Can this be fixed before JDK 12? I will not able to compile java 12 > 32bits > > because I will not have java 11 32bits as a boot-jdk. > > > > El sáb., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( > > david.hol...@oracle.com) escribió: > > > >> On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: > >>> On 2018-11-23 08:35, Franco Gastón Pellegrini wrote: > Using the same command as before, and then using > make CONF=windows-x86-normal-client-fastdebug clean; > make CONF=windows-x86-normal-client-fastdebug; > > I get warnings as error, and cannot compile. The output is (and I > attached the logs): > > $ make CONF=windows-x86-normal-client-fastdebug; > Building target 'default (exploded-image)' in configuration > 'windows-x86-normal-client-fastdebug' > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > Compiling 2 files for BUILD_JVMTI_TOOLS > Compiling 1 files for BUILD_JFR_TOOLS > Compiling 12 properties into resource bundles for jdk.jdeps > Compiling 7 properties into resource bundles for jdk.jshell > Parsing 2 properties into enum-like class for jdk.compiler > Compiling 19 properties into resource bundles for jdk.compiler > Compiling 13 properties into resource bundles for jdk.javadoc > Compiling 117 files for BUILD_java.compiler.interim > Compiling 394 files for BUILD_jdk.compiler.interim > Creating support/modules_libs/java.base/client/jvm.dll from 746 > file(s) > Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s) > Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 > file(s) > Compiling 299 files for BUILD_jdk.javadoc.interim > Compiling 162 files for BUILD_TOOLS_JDK > Compiling 188 files for BUILD_jdk.rmic.interim > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 2 files for COMPILE_DEPEND > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Compiling 2 files for BUILD_BREAKITERATOR_BASE > Compiling 2 files for BUILD_BREAKITERATOR_LD > SocketOptionRegistry.java.template > Compiling 11 properties into resource bundles for java.base > Compiling 6 properties into resource bundles for java.base > Compiling 11 properties into resource bundles for java.logging > Compiling 11 properties into resource bundles for jdk.jartool > Compiling 11 properties into resource bundles for jdk.management.agent > > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > error C2220: warning treated as error - no 'object' file generated > > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > >> > warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of > data > make[3]: *** [lib/CompileJvm.gmk:151: > > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj] > >> > Error 1 > >>> 32-bit Windows is not regularly built, and might become unbuildable > from > >>> time to time. I think you are running into > >>> https://bugs.openjdk.java.net/browse/JDK-8214206, which has a patch > out > >>> for review. > >> No, this isn't JDK-8214206 - that was caused by a change only in JDK 12. > >> > >> But the above must have been fixed at some point as 32-bit builds in > >> mainline are being done fairly regularly. (We have ARM 32-bit in our > >> tier 5 now). > >> > >> David > >> > >>> /Magnus > >>> > >>> > make[3]: *** Waiting for unfinished jobs > make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2 > make[2]: *** Waiting for unfinished jobs > Compiling 4 properties into resource bundles for jdk.jlink > Compiling 3 properties into resource bundles for jdk.jdi > Compiling 3 properties into resource bundles for jdk.jlink > Compiling 1 properties into resource bundles for jdk.jlink > > ERROR: Build failed for target 'default (exploded-image)' in > configuration 'windows-x86-normal-client-fastdebug' (exit code 2) > > === Output from failing command(s) repeated here === > * For target
Re: compiling openJdk 11 on windows 7 32bits fail
If you are running into warnings treated as errors, please try configuring with --disable-warnings-as-errors. That is often needed on less tested platforms. Note that as long as you run the build on a 64 bit system, you can use a 64 bit bootjdk to build a 32 bit JDK. /Erik On 2019-02-06 11:07, Franco Gastón Pellegrini wrote: Can this be fixed before JDK 12? I will not able to compile java 12 32bits because I will not have java 11 32bits as a boot-jdk. El sáb., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( david.hol...@oracle.com) escribió: On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: On 2018-11-23 08:35, Franco Gastón Pellegrini wrote: Using the same command as before, and then using make CONF=windows-x86-normal-client-fastdebug clean; make CONF=windows-x86-normal-client-fastdebug; I get warnings as error, and cannot compile. The output is (and I attached the logs): $ make CONF=windows-x86-normal-client-fastdebug; Building target 'default (exploded-image)' in configuration 'windows-x86-normal-client-fastdebug' Compiling 8 files for BUILD_TOOLS_LANGTOOLS Compiling 2 files for BUILD_JVMTI_TOOLS Compiling 1 files for BUILD_JFR_TOOLS Compiling 12 properties into resource bundles for jdk.jdeps Compiling 7 properties into resource bundles for jdk.jshell Parsing 2 properties into enum-like class for jdk.compiler Compiling 19 properties into resource bundles for jdk.compiler Compiling 13 properties into resource bundles for jdk.javadoc Compiling 117 files for BUILD_java.compiler.interim Compiling 394 files for BUILD_jdk.compiler.interim Creating support/modules_libs/java.base/client/jvm.dll from 746 file(s) Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s) Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 file(s) Compiling 299 files for BUILD_jdk.javadoc.interim Compiling 162 files for BUILD_TOOLS_JDK Compiling 188 files for BUILD_jdk.rmic.interim Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 2 files for COMPILE_DEPEND Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Compiling 2 files for BUILD_BREAKITERATOR_BASE Compiling 2 files for BUILD_BREAKITERATOR_LD SocketOptionRegistry.java.template Compiling 11 properties into resource bundles for java.base Compiling 6 properties into resource bundles for java.base Compiling 11 properties into resource bundles for java.logging Compiling 11 properties into resource bundles for jdk.jartool Compiling 11 properties into resource bundles for jdk.management.agent c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): error C2220: warning treated as error - no 'object' file generated c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data make[3]: *** [lib/CompileJvm.gmk:151: /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj] Error 1 32-bit Windows is not regularly built, and might become unbuildable from time to time. I think you are running into https://bugs.openjdk.java.net/browse/JDK-8214206, which has a patch out for review. No, this isn't JDK-8214206 - that was caused by a change only in JDK 12. But the above must have been fixed at some point as 32-bit builds in mainline are being done fairly regularly. (We have ARM 32-bit in our tier 5 now). David /Magnus make[3]: *** Waiting for unfinished jobs make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2 make[2]: *** Waiting for unfinished jobs Compiling 4 properties into resource bundles for jdk.jlink Compiling 3 properties into resource bundles for jdk.jdi Compiling 3 properties into resource bundles for jdk.jlink Compiling 1 properties into resource bundles for jdk.jlink ERROR: Build failed for target 'default (exploded-image)' in configuration 'windows-x86-normal-client-fastdebug' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: classFileParser.cpp c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): error C2220: warning treated as error - no 'object' file generated c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of data ... (rest of output omitted) * All command lines available in /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/make-support/failure-logs. === End of repeated output === El jue., 22 de nov. de 2018 a la(s) 22:19, Franco Gastón Pellegrini (francogpellegr...@gmail.com
Re: compiling openJdk 11 on windows 7 32bits fail
Can this be fixed before JDK 12? I will not able to compile java 12 32bits because I will not have java 11 32bits as a boot-jdk. El sáb., 24 de nov. de 2018 a la(s) 03:59, David Holmes ( david.hol...@oracle.com) escribió: > On 23/11/2018 7:10 pm, Magnus Ihse Bursie wrote: > > > > On 2018-11-23 08:35, Franco Gastón Pellegrini wrote: > >> Using the same command as before, and then using > >> make CONF=windows-x86-normal-client-fastdebug clean; > >> make CONF=windows-x86-normal-client-fastdebug; > >> > >> I get warnings as error, and cannot compile. The output is (and I > >> attached the logs): > >> > >> $ make CONF=windows-x86-normal-client-fastdebug; > >> Building target 'default (exploded-image)' in configuration > >> 'windows-x86-normal-client-fastdebug' > >> Compiling 8 files for BUILD_TOOLS_LANGTOOLS > >> Compiling 2 files for BUILD_JVMTI_TOOLS > >> Compiling 1 files for BUILD_JFR_TOOLS > >> Compiling 12 properties into resource bundles for jdk.jdeps > >> Compiling 7 properties into resource bundles for jdk.jshell > >> Parsing 2 properties into enum-like class for jdk.compiler > >> Compiling 19 properties into resource bundles for jdk.compiler > >> Compiling 13 properties into resource bundles for jdk.javadoc > >> Compiling 117 files for BUILD_java.compiler.interim > >> Compiling 394 files for BUILD_jdk.compiler.interim > >> Creating support/modules_libs/java.base/client/jvm.dll from 746 file(s) > >> Creating hotspot/variant-client/libjvm/gtest/jvm.dll from 90 file(s) > >> Creating hotspot/variant-client/libjvm/gtest/gtestLauncher.exe from 1 > >> file(s) > >> Compiling 299 files for BUILD_jdk.javadoc.interim > >> Compiling 162 files for BUILD_TOOLS_JDK > >> Compiling 188 files for BUILD_jdk.rmic.interim > >> Note: Some input files use or override a deprecated API. > >> Note: Recompile with -Xlint:deprecation for details. > >> Note: Some input files use unchecked or unsafe operations. > >> Note: Recompile with -Xlint:unchecked for details. > >> Compiling 2 files for COMPILE_DEPEND > >> Note: Some input files use or override a deprecated API. > >> Note: Recompile with -Xlint:deprecation for details. > >> Compiling 2 files for BUILD_BREAKITERATOR_BASE > >> Compiling 2 files for BUILD_BREAKITERATOR_LD > >> SocketOptionRegistry.java.template > >> Compiling 11 properties into resource bundles for java.base > >> Compiling 6 properties into resource bundles for java.base > >> Compiling 11 properties into resource bundles for java.logging > >> Compiling 11 properties into resource bundles for jdk.jartool > >> Compiling 11 properties into resource bundles for jdk.management.agent > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >> error C2220: warning treated as error - no 'object' file generated > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of > >> data > >> make[3]: *** [lib/CompileJvm.gmk:151: > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/hotspot/variant-client/libjvm/objs/classFileParser.obj] > > >> Error 1 > > > > 32-bit Windows is not regularly built, and might become unbuildable from > > time to time. I think you are running into > > https://bugs.openjdk.java.net/browse/JDK-8214206, which has a patch out > > for review. > > No, this isn't JDK-8214206 - that was caused by a change only in JDK 12. > > But the above must have been fixed at some point as 32-bit builds in > mainline are being done fairly regularly. (We have ARM 32-bit in our > tier 5 now). > > David > > > /Magnus > > > > > >> make[3]: *** Waiting for unfinished jobs > >> make[2]: *** [make/Main.gmk:257: hotspot-client-libs] Error 2 > >> make[2]: *** Waiting for unfinished jobs > >> Compiling 4 properties into resource bundles for jdk.jlink > >> Compiling 3 properties into resource bundles for jdk.jdi > >> Compiling 3 properties into resource bundles for jdk.jlink > >> Compiling 1 properties into resource bundles for jdk.jlink > >> > >> ERROR: Build failed for target 'default (exploded-image)' in > >> configuration 'windows-x86-normal-client-fastdebug' (exit code 2) > >> > >> === Output from failing command(s) repeated here === > >> * For target hotspot_variant-client_libjvm_objs_classFileParser.obj: > >> classFileParser.cpp > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >> error C2220: warning treated as error - no 'object' file generated > >> > c:/cygwin/home/Franco/Java/jdk11/src/hotspot/share/classfile/classFileParser.cpp(310): > > >> warning C4267: '=': conversion from 'size_t' to 'u2', possible loss of > >> data > >>... (rest of output omitted) > >> > >> * All command lines available in > >> > /cygdrive/c/cygwin/home/Franco/Java/jdk11/build/windows-x86-normal-client-fastdebug/make-support/failure-logs. > > >> > >> === End of repeated output === > >> > >> El
Re: RFR: JDK-8218431 Improved platform checking in makefiles
Thanks, looks good! /Erik On 2019-02-06 07:39, Magnus Ihse Bursie wrote: On 2019-02-05 18:31, Magnus Ihse Bursie wrote: On 2019-02-05 18:01, Erik Joelsson wrote: Looks good. I have read through all of them and it does not seem like you got any wrong. I note that you chose to express negatives as: ifneq (isTargetFoo, true) instead of: ifeq (isTargetFoo, false) I think I would have preferred the latter, given that the new macros return both true and false. I think true/false is more obvious to the eye than the sneaky 'n' in ifneq, but I don't have a strong opinion so this is fine too. I did consider this. I was on the verge of actually sending a question to the list, asking for input on this choice. My reasoning was I'm personally a bit blind to the "false" part, from all the years of focusing on the ifeq/ifneq, and that "ifeq foo, false" feels a bit like the newbie "if (mybool == false)" construct. But I also agree with your stance. As long as we agree to use one standard, I'll be happy to switch to "ifeq ... false". I think the important thing is just that we don't have to look out for both "ifneq ... true" and "ifeq ... false". Here is an updated webrev, that uses "ifeq" always (and tests for false instead): http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.03 I encountered one complicating issue. Statements such as this: ifneq ($(call isTargetOs, windows)+$(call isTargetCpu, x86_64), true+true) did not trivially allow themselves to be rewritten without ifneq. So I went ahead and fixed the two boolean operators And and Or, that I've been missing for a while. So, then I could rewrite it as: ifeq ($(call And, $(call isTargetOs, windows) $(call isTargetCpu, x86_64)), false) (I tried naming it "and" but it clashed with the GNU Make 4.0 $(and ...) function. (Which is not usable for us, since it considers "false" to be true.) I only used And, but created Or as well for completeness. /Magnus /Magnus /Erik On 2019-02-05 07:28, Magnus Ihse Bursie wrote: On 2019-02-05 15:49, Magnus Ihse Bursie wrote: To check for various aspects of the build or target platform, we do a lot of checks like: ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) ... The naming of those platform information variables is a bit unfortunate. Yes, we know we're building OpenJDK, so why the OPENJDK_ prefix? I've been wanting for a long time to do something about this odd prefix, and it became more urgent after the recent fix of JDK-8160926, which pushes the matter about unifying the naming of build/target variables. The solution in this patch is not to rename the variables per se, but to introduce an abstraction layer in terms of function calls for checking platform aspects. This *really* shines when it comes to testing for multiple platforms. Previously, we were required to resort to constructs such as: ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) but this can now be expressed as: ifeq ($(call isTargetOs, windows solaris), true) Or this (actually technically broken) horrible example: ifneq (, $(findstring $(OPENJDK_TARGET_OS), linux macosx)) which I had to read three times before being sure that this was the correct way to replace it: ifeq ($(call isTargetOs, linux macosx), true) Bug: https://bugs.openjdk.java.net/browse/JDK-8218431 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.01 ... and here's an updated version that fixes a typo: http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.02 /Magnus /Magnus
Re: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings
On 2019-02-06 16:17, Baesken, Matthias wrote: Hello, please review this small change . I noticed (when looking into AIX xlc16 / xlclang++) the following:in the case that clang is used for compilation,HOTSPOT_BUILD_COMPILER claims to be a gcc . This is a bit misleading. This change adjusts the setting for clang usage on AIX (for future usage with xlclang++) and macOSX. Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy Oracle / Sun Studio versions ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8218562 http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ Looks good to me. /Magnus Thanks, Matthias
Re: RFR: JDK-8218431 Improved platform checking in makefiles
On 2019-02-05 18:31, Magnus Ihse Bursie wrote: On 2019-02-05 18:01, Erik Joelsson wrote: Looks good. I have read through all of them and it does not seem like you got any wrong. I note that you chose to express negatives as: ifneq (isTargetFoo, true) instead of: ifeq (isTargetFoo, false) I think I would have preferred the latter, given that the new macros return both true and false. I think true/false is more obvious to the eye than the sneaky 'n' in ifneq, but I don't have a strong opinion so this is fine too. I did consider this. I was on the verge of actually sending a question to the list, asking for input on this choice. My reasoning was I'm personally a bit blind to the "false" part, from all the years of focusing on the ifeq/ifneq, and that "ifeq foo, false" feels a bit like the newbie "if (mybool == false)" construct. But I also agree with your stance. As long as we agree to use one standard, I'll be happy to switch to "ifeq ... false". I think the important thing is just that we don't have to look out for both "ifneq ... true" and "ifeq ... false". Here is an updated webrev, that uses "ifeq" always (and tests for false instead): http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.03 I encountered one complicating issue. Statements such as this: ifneq ($(call isTargetOs, windows)+$(call isTargetCpu, x86_64), true+true) did not trivially allow themselves to be rewritten without ifneq. So I went ahead and fixed the two boolean operators And and Or, that I've been missing for a while. So, then I could rewrite it as: ifeq ($(call And, $(call isTargetOs, windows) $(call isTargetCpu, x86_64)), false) (I tried naming it "and" but it clashed with the GNU Make 4.0 $(and ...) function. (Which is not usable for us, since it considers "false" to be true.) I only used And, but created Or as well for completeness. /Magnus /Magnus /Erik On 2019-02-05 07:28, Magnus Ihse Bursie wrote: On 2019-02-05 15:49, Magnus Ihse Bursie wrote: To check for various aspects of the build or target platform, we do a lot of checks like: ifeq ($(OPENJDK_BUILD_OS_ENV), windows.cygwin) ... The naming of those platform information variables is a bit unfortunate. Yes, we know we're building OpenJDK, so why the OPENJDK_ prefix? I've been wanting for a long time to do something about this odd prefix, and it became more urgent after the recent fix of JDK-8160926, which pushes the matter about unifying the naming of build/target variables. The solution in this patch is not to rename the variables per se, but to introduce an abstraction layer in terms of function calls for checking platform aspects. This *really* shines when it comes to testing for multiple platforms. Previously, we were required to resort to constructs such as: ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), ) but this can now be expressed as: ifeq ($(call isTargetOs, windows solaris), true) Or this (actually technically broken) horrible example: ifneq (, $(findstring $(OPENJDK_TARGET_OS), linux macosx)) which I had to read three times before being sure that this was the correct way to replace it: ifeq ($(call isTargetOs, linux macosx), true) Bug: https://bugs.openjdk.java.net/browse/JDK-8218431 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.01 ... and here's an updated version that fixes a typo: http://cr.openjdk.java.net/~ihse/JDK-8218431-improved-platform-checking/webrev.02 /Magnus /Magnus
RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings
Hello, please review this small change . I noticed (when looking into AIX xlc16 / xlclang++) the following:in the case that clang is used for compilation,HOTSPOT_BUILD_COMPILER claims to be a gcc . This is a bit misleading. This change adjusts the setting for clang usage on AIX (for future usage with xlclang++) and macOSX. Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy Oracle / Sun Studio versions ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8218562 http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ Thanks, Matthias
Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX
On 2019-02-06 09:05, Baesken, Matthias wrote: Thank's Götz ! David + Magnus may I add you as reviewers ? Sure. /Magnus Best regards, Matthias -Original Message- From: Lindenmaier, Goetz Sent: Dienstag, 5. Februar 2019 18:05 To: Baesken, Matthias ; David Holmes ; 'hotspot-...@openjdk.java.net' ; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX looks good, thanks for the adjustment! Best regards, Goetz. -Original Message- From: Baesken, Matthias Sent: Dienstag, 5. Februar 2019 17:56 To: Lindenmaier, Goetz ; David Holmes ; 'hotspot-...@openjdk.java.net' ; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Hi Götz, new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ The old xlc stuff is good to be removed. Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN altogether and replace its only use by USE_XLC_BUILTINS? Done . Also, I think it makes sense to put #if __IBMCPP__ < 1000 #error "xlc < 10 not supported" #endif into the file. Probably we should even check for having at least xlc 12. I added a check for xlc 12. Also slightly changed the check for AIX (_AIX macro) in globalDefinitions_xlc.hpp . The demangle fix is kind of preliminary, but to get the compiler working it is acceptable to skip this code for now. There might be a fix for xlc16 in the future but so far we have to live with it. Best regards, Matthias -Original Message- From: Lindenmaier, Goetz Sent: Dienstag, 5. Februar 2019 09:59 To: Baesken, Matthias ; David Holmes ; 'hotspot-...@openjdk.java.net' d...@openjdk.java.net>; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Hi Matthias, The demangle fix is kind of preliminary, but to get the compiler working it is acceptable to skip this code for now. The old xlc stuff is good to be removed. Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN altogether and replace its only use by USE_XLC_BUILTINS? Also, I think it makes sense to put #if __IBMCPP__ < 1000 #error "xlc < 10 not supported" #endif into the file. Probably we should even check for having at least xlc 12. Best regards, Goetz. -Original Message- From: hotspot-dev On Behalf Of Baesken, Matthias Sent: Montag, 4. Februar 2019 12:36 To: David Holmes ; 'hotspot- d...@openjdk.java.net' ; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Hi David, I want to follow your suggestion . I adjusted the comment , see globalDefinitions_xlc.hpp . Additionally I removed a strange ifdef handling pre-xlc10 versions that are not useful today any more for OpenJDK ( we most likely cannot build jdk/jdk with xlc versions < 10). New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ Best regards, Matthias -Original Message- From: David Holmes Sent: Freitag, 1. Februar 2019 13:49 To: Baesken, Matthias ; 'hotspot- d...@openjdk.java.net' ; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Hi Matthias, On 1/02/2019 10:36 pm, Baesken, Matthias wrote: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ - adjusted globalDefinitions_xlc.hpp I don't think it makes sense to keep the comment which was obviously copied from the gcc file: // On Linux NULL is defined as a special type '__null'. Assigning __null to // integer variable will cause gcc warning. Use NULL_WORD in places where a // pointer is stored as integer value. On some platforms, sizeof(intptr_t) > // sizeof(void*), so here we want something which is integer type, but has the // same size as a pointer. Rather something like: // Some platform/tool-chain combinations can't assign NULL to an integer // type so we define NULL_WORD to use in those contexts. For xlc they // are the same. Thanks, David
Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX
On 6/02/2019 6:05 pm, Baesken, Matthias wrote: Thank's Götz ! David + Magnus may I add you as reviewers ? Sure - though my review was only partial. You seem to have it all covered now. :) Thanks, David Best regards, Matthias -Original Message- From: Lindenmaier, Goetz Sent: Dienstag, 5. Februar 2019 18:05 To: Baesken, Matthias ; David Holmes ; 'hotspot-...@openjdk.java.net' ; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX looks good, thanks for the adjustment! Best regards, Goetz. -Original Message- From: Baesken, Matthias Sent: Dienstag, 5. Februar 2019 17:56 To: Lindenmaier, Goetz ; David Holmes ; 'hotspot-...@openjdk.java.net' ; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Hi Götz, new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ The old xlc stuff is good to be removed. Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN altogether and replace its only use by USE_XLC_BUILTINS? Done . Also, I think it makes sense to put #if __IBMCPP__ < 1000 #error "xlc < 10 not supported" #endif into the file. Probably we should even check for having at least xlc 12. I added a check for xlc 12. Also slightly changed the check for AIX (_AIX macro) in globalDefinitions_xlc.hpp . The demangle fix is kind of preliminary, but to get the compiler working it is acceptable to skip this code for now. There might be a fix for xlc16 in the future but so far we have to live with it. Best regards, Matthias -Original Message- From: Lindenmaier, Goetz Sent: Dienstag, 5. Februar 2019 09:59 To: Baesken, Matthias ; David Holmes ; 'hotspot-...@openjdk.java.net' d...@openjdk.java.net>; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Hi Matthias, The demangle fix is kind of preliminary, but to get the compiler working it is acceptable to skip this code for now. The old xlc stuff is good to be removed. Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN altogether and replace its only use by USE_XLC_BUILTINS? Also, I think it makes sense to put #if __IBMCPP__ < 1000 #error "xlc < 10 not supported" #endif into the file. Probably we should even check for having at least xlc 12. Best regards, Goetz. -Original Message- From: hotspot-dev On Behalf Of Baesken, Matthias Sent: Montag, 4. Februar 2019 12:36 To: David Holmes ; 'hotspot- d...@openjdk.java.net' ; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Hi David, I want to follow your suggestion . I adjusted the comment , see globalDefinitions_xlc.hpp . Additionally I removed a strange ifdef handling pre-xlc10 versions that are not useful today any more for OpenJDK ( we most likely cannot build jdk/jdk with xlc versions < 10). New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ Best regards, Matthias -Original Message- From: David Holmes Sent: Freitag, 1. Februar 2019 13:49 To: Baesken, Matthias ; 'hotspot- d...@openjdk.java.net' ; 'magnus.ihse.bur...@oracle.com' Cc: 'build-dev@openjdk.java.net' Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX Hi Matthias, On 1/02/2019 10:36 pm, Baesken, Matthias wrote: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ - adjusted globalDefinitions_xlc.hpp I don't think it makes sense to keep the comment which was obviously copied from the gcc file: // On Linux NULL is defined as a special type '__null'. Assigning __null to // integer variable will cause gcc warning. Use NULL_WORD in places where a // pointer is stored as integer value. On some platforms, sizeof(intptr_t) > // sizeof(void*), so here we want something which is integer type, but has the // same size as a pointer. Rather something like: // Some platform/tool-chain combinations can't assign NULL to an integer // type so we define NULL_WORD to use in those contexts. For xlc they // are the same. Thanks, David
RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX
Thank's Götz ! David + Magnus may I add you as reviewers ? Best regards, Matthias > -Original Message- > From: Lindenmaier, Goetz > Sent: Dienstag, 5. Februar 2019 18:05 > To: Baesken, Matthias ; David Holmes > ; 'hotspot-...@openjdk.java.net' d...@openjdk.java.net>; 'magnus.ihse.bur...@oracle.com' > > Cc: 'build-dev@openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > looks good, thanks for the adjustment! > > Best regards, > Goetz. > > > -Original Message- > > From: Baesken, Matthias > > Sent: Dienstag, 5. Februar 2019 17:56 > > To: Lindenmaier, Goetz ; David Holmes > > ; 'hotspot-...@openjdk.java.net' > d...@openjdk.java.net>; 'magnus.ihse.bur...@oracle.com' > > > > Cc: 'build-dev@openjdk.java.net' > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi Götz, new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ > > > > > > > The old xlc stuff is good to be removed. > > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > > > > Done . > > > > > Also, I think it makes sense to put > > > #if __IBMCPP__ < 1000 > > > #error "xlc < 10 not supported" > > > #endif > > > into the file. > > > > > > Probably we should even check for having at least xlc 12. > > > > I added a check for xlc 12. > > Also slightly changed the check for AIX (_AIX macro) in > > globalDefinitions_xlc.hpp . > > > > > > > > > > The demangle fix is kind of preliminary, but to get the compiler > > > working it is acceptable to skip this code for now. > > > > > > > There might be a fix for xlc16 in the future but so far we have to live > > with > it. > > > > > > Best regards, Matthias > > > > > > > > > -Original Message- > > > From: Lindenmaier, Goetz > > > Sent: Dienstag, 5. Februar 2019 09:59 > > > To: Baesken, Matthias ; David Holmes > > > ; 'hotspot-...@openjdk.java.net' > > > d...@openjdk.java.net>; 'magnus.ihse.bur...@oracle.com' > > > > > > Cc: 'build-dev@openjdk.java.net' > > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > > xlc16 on AIX > > > > > > Hi Matthias, > > > > > > The demangle fix is kind of preliminary, but to get the compiler > > > working it is acceptable to skip this code for now. > > > > > > The old xlc stuff is good to be removed. > > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > > > Also, I think it makes sense to put > > > #if __IBMCPP__ < 1000 > > > #error "xlc < 10 not supported" > > > #endif > > > into the file. > > > > > > Probably we should even check for having at least xlc 12. > > > > > > Best regards, > > > Goetz. > > > > > > > -Original Message- > > > > From: hotspot-dev On > Behalf > > > Of > > > > Baesken, Matthias > > > > Sent: Montag, 4. Februar 2019 12:36 > > > > To: David Holmes ; 'hotspot- > > > > d...@openjdk.java.net' ; > > > > 'magnus.ihse.bur...@oracle.com' > > > > Cc: 'build-dev@openjdk.java.net' > > > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ > from > > > > xlc16 on AIX > > > > > > > > Hi David, I want to follow your suggestion . > > > > I adjusted the comment , see globalDefinitions_xlc.hpp . > > > > > > > > Additionally I removed a strange ifdef handling pre-xlc10 versions > > > > that > are > > > > not useful today any more for OpenJDK > > > > ( we most likely cannot build jdk/jdk with xlc versions < 10). > > > > > > > > New webrev : > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > > > > > > > > > > Best regards, Matthias > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: David Holmes > > > > > Sent: Freitag, 1. Februar 2019 13:49 > > > > > To: Baesken, Matthias ; 'hotspot- > > > > > d...@openjdk.java.net' ; > > > > > 'magnus.ihse.bur...@oracle.com' > > > > > Cc: 'build-dev@openjdk.java.net' > > > > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ > from > > > > > xlc16 on AIX > > > > > > > > > > Hi Matthias, > > > > > > > > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > > > > > New webrev : > > > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > > > > > > > > > - adjusted globalDefinitions_xlc.hpp > > > > > > > > > > I don't think it makes sense to keep the comment which was > obviously > > > > > copied from the gcc file: > > > > > > > > > > // On Linux NULL is defined as a special type '__null'. Assigning > > > > > __null to > > > > >// integer variable will cause gcc warning. Use NULL_WORD in places > > > > > where a > > > > >// pointer is stored as integer value. On some platforms, > > > > > sizeof(intptr_t) > > > > > >// sizeof(void*), so here we want something which is integer type, > > > > > but has the > > > > >// same
