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

Fri Feb 15 12:31:37 UTC 2019

On 2019-02-15 12:53, Baesken, Matthias wrote:
> 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 ).

Ok, that's good to hear.
>
>> 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)
Hm.

Are they both pointing to the same binary, and the mode of operation 
(legacy xlc vs xlclang) is determined by the name of the executable?

Is xlclang++ always available for version 16+ of xlc?

If so, maybe we should just make sure we call the compiler with the 
correct name if version 16+ is detected?

Or is there a way to force xlclang mode using a flag?

/Magnus

>
> 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