Hi Magnus, we are currently able to build (+ test 😊 ) jdk/jdk on AIX with the xlclang++ based build . Only needed are this change , plus a one-liner in harfhuzz is needed (we try to get this upstream into harbuzz directly, in case the next harfhuzz update to jdk/jdk is in the mid/far future , I would add this one liner to my patch).
So I hope that there will be not so many follow ups (but you never know ). > > If so, could the choice between -g ang -g1 be handled with the normal > TOOLCHAIN_CHECK_COMPILER_VERSION? > I'll look into this . Unfortunately the version output is the same for both frontends : New one: bash-4.4$ xlclang++ -qversion IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) Version: 16.01.0000.0001 Legacy xlc: bash-4.4$ xlC_r -qversion IBM XL C/C++ for AIX, V16.1.0 (some-strange-hex-string) Version: 16.01.0000.0001 (and some-strange-hex-string is the same for both) Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> > Sent: Freitag, 15. Februar 2019 12:37 > To: Baesken, Matthias <matthias.baes...@sap.com>; 'build- > d...@openjdk.java.net' <build-dev@openjdk.java.net> > Subject: Re: RFR : 8218965: aix: support xlclang++ in the compiler detection > > On 2019-02-15 09:31, Baesken, Matthias wrote: > > Hi Magnus , I think it is not a separate toolchain , just another > > compiler > frontend offered by the xlc toolchain of xlc16 . > So will this distinction between xlc and xlclang be needed elsewhere? Or > is it just the -g flag? I was worried that this was just the start of a > flood of changes related to xlc vs xlclang, but maybe this is all that > is needed? > > If so, could the choice between -g ang -g1 be handled with the normal > TOOLCHAIN_CHECK_COMPILER_VERSION? > > /Magnus > > > Our current toolchains are : > > > > # These toolchains are valid on different platforms > > VALID_TOOLCHAINS_linux="gcc clang" > > VALID_TOOLCHAINS_solaris="solstudio" > > VALID_TOOLCHAINS_macosx="gcc clang" > > VALID_TOOLCHAINS_aix="xlc" > > VALID_TOOLCHAINS_windows="microsoft" > > > > # Toolchain descriptions > > TOOLCHAIN_DESCRIPTION_clang="clang/LLVM" > > TOOLCHAIN_DESCRIPTION_gcc="GNU Compiler Collection" > > TOOLCHAIN_DESCRIPTION_microsoft="Microsoft Visual Studio" > > TOOLCHAIN_DESCRIPTION_solstudio="Oracle Solaris Studio" > > TOOLCHAIN_DESCRIPTION_xlc="IBM XL C/C++" > > > > > > XLC16 /xlclang++ identifies itself as : > > > > xlclang++ -qversion > > IBM XL C/C++ for AIX, V16.1.0 > > > > > > In the long run , with JEP 347: Adopt C++14 Language Features in HotSpot > , the legacy XlC_r will most likely not be usable any more to build > the HS > codebase . > > Then we must go to another compiler , and xlclang++ is the choice I > > think . > > > > (other option is to discontinue the AIX support in OpenJDK, or strip > down JEP 347 to some C++ 11 features supported by the legacy XlC_r ). > > So then we do not really need such a detection any more and have to go > for the usable tool . > > > >> We try to use "true" and "false" as values for boolean variable, so > >> "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". > >> > > Good point. > > > >> The test to determine if we're using xlclang seem to happen in the wrong > >> location. It also calls the bare "xlclang++" from the path, without any > >> consideration if the user has specified a toolchain path, etc. > >> > > I think this is how it is currently done on AIX for years, you just put > > xlc in > the PATH and then let configure find it there. > > However you are right on this one , toolchain path settings should be > supported ( not sure whether they currently work or not). > > In our AIX envs they are not of much use, because we have ***one*** > xlc per machine ( I am not even sure if it is 100% supported to have > multiple xlc in parallel on one machine, > > guess it somehow works but is not officially recommended ). > > > >> I won't go into more details on the patch until we've determined if this > >> is the solution we should pursue. > >> > > There is no need to rush the patch in , for now the legacy xlc_r still > > works > ( until the C++11/14 features show up ) . > > > > Best regards, Matthias > > > > > > > >>> please review this small change . > >>> > >>> On AIX, it adds detection of xlc16 / clang to the build > >>> environment. > >>> > >>> The xlc16 package contains 2 compiler frontends : > >>> > >>> > >>> * The legacy xlc > >>> * The new clang-based xlclang++ > >>> > >>> For older xlc (12 / 13) we should for now still support the "legacy" > >>> xlc . > >>> For xlc16 the usage of xlclang++ is desired , because it > >>> promises > >> better C++11/14 support (important for the coming JEPs dealing with > >> C++11/14 features) . > >>> Additionally to the compiler detection , the debug-flag is changed to -g1 > >> when xlclang++ is used (because of issues with -g) ; thanks to Steven > >> for > >> providing the info. > >>> > >>> > >>> Bug/webrev : > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8218965 > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218965.0/ > >> Hi Matthias, > >> > >> I have several doubts about this patch. > >> > >> Let me start at the highest level before dwelling on details. > >> > >> Is this really the right way to handle this? Maybe we should either > >> treat xlclang as a new, separate toolchain, or we should treat xlclang > >> as a variant of the clang toolchain. > >> > >> If xlclang is very similar to clang (same compilation behavior, same > >> compiler flags), then I believe the latter way is the proper way forward. > >> > >> If xlclang is -- even though the change of frontend -- mostly similar to > >> the traditional xlc, then the path chosen by you might be the best way > >> forward after all. > >> > >> If xlclang is different enought from both the traditional xlc, and from > >> clang, we might want to treat it like an entirely new toolchain. We can > >> of course share code with the existing xlc and clang toolchains. I think > >> this is the best way if e.g. compiler flags are still shared with xlc, > >> but source code defines etc is shared with clang. That way we can test > >> for "xlc or xlclang" when setting up flags, but "clang or xlclang" in > >> the #ifdefs. > >> > >> --- > >> > >> If we should go forward with your patch, please note the following: > >> > >> We try to use "true" and "false" as values for boolean variable, so > >> "AIX_USE_CLANG=1" should be "AIX_USE_CLANG=true". > >> > >> The test to determine if we're using xlclang seem to happen in the wrong > >> location. It also calls the bare "xlclang++" from the path, without any > >> consideration if the user has specified a toolchain path, etc. > >> > >> I won't go into more details on the patch until we've determined if this > >> is the solution we should pursue. > >> > >> /Magnus > >>> > >>> > >>> Thanks, Matthias
