RFR : 8218965: aix: support xlclang++ in the compiler detection

Fri Feb 15 11:53:37 UTC 2019

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.bursie at oracle.com>
> Sent: Freitag, 15. Februar 2019 12:37
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> dev at openjdk.java.net' <build-dev at 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