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

Fri Feb 15 11:37:16 UTC 2019

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