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