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

[Baesken, Matthias]

Hi Magnus , I think  it is not a separate  toolchain ,  just  another compiler frontend offered by the xlc toolchain of  xlc16 .
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