XL: Add support for xlclang front end

IBM XL 16.1 comes with new xlclang and xlclang++ front ends. CMake will need some work to support these, perhaps with a new compiler id (IBMClang?).

Cc: @chuck @chuck.atkins

mentioned in issue #18460 (closed)

For reference, the xlclang++ front-end is needed to get full C++11 support from the XL compiler.

Another possible new compiler id is XLClang, which may be better than IBMClang because XLClang is pronounced the same way as xlclang.

We need a way to distinguish xlclang++ from xlC via the preprocessor. Based on some experiments:

• __ibmxl__ is defined by xlC 13.1.6 and higher on Linux.
• __ibmxl__ is defined by xlclang++ 16.1 on AIX.
• __ibmxl__ is not defined by xlC 16.1 on AIX.

Since __ibmxl__ may be defined by either xlC or xlclang++ we cannot rely on it to distinguish them.

Thanks for your work on this, and you're correct that the xlclang++ front-end is needed to get full C++11 support from the XL compiler. I also think an XLClang id is better than IBMClang for the reason you mentioned.

As for a macro to distinguish xlclang++ and xlC, how about using macro __xlC__? On AIX, if __xlC__ is set, you are using xlC, and if it is not set, you are using xlclang++ (see the Knowledge Center docs). Will it be an issue that on Linux, __xlC__ is not set by default? You can have xlC set it on Linux by using compiler option -qxlcompatmacros. On Linux (16.1.1), the xlclang++ invocation is not offered, just xlC is.

Thanks. Perhaps defined(__ibmxl__) && defined(_AIX) && !defined(__xlC__) can be used to identify xlclang on AIX. Is there an xlclang for Linux, or is there no reason for that because upstream Clang works there?

Just for information: __xlC__ can be set on AIX by xlclang++ when -qxlcompatmacros is used.

Currently, using xlclang++ with -qxlcompatmacros produces a CMAKE_CXX_COMPILER_ID of XL. It may be desirable to leave the detection as XL (i.e., have !defined(__xlC__) as part of the condition as proposed) to maintain compatibility for CMake builds that are currently relying on this.

As xlclang++ is new it is fair game to change behavior for it in a new CMake release. Please don't rely on it having a compiler id of XL. We must have a distinct compiler id for it because the command-line flags are completely different than xlC.

If -qxlcompatmacros causes __xlC__ then we need something else. It sounds like there may not be a way to distinguish the two command-line tools via the preprocessor. We may need to use the *_COMPILER_ID_VENDOR_FLAGS_* table method instead (grep for that in the Modules directory to see what it is).

__ibmxl__ is not defined by xlC; so, the two invocations can be distinguished.

__ibmxl__ is not defined by xlC

Thanks. It is on Linux, so we still need to condition on _AIX.

To give some more background, both XL C/C++ for AIX 16.1 and XL C/C++ for Linux (little endian) offer a compiler invocation which combines the Clang front end infrastructure with the advanced optimization technology in the IBM compiler back end. XL C/C++ for AIX 16.1 offers 2 invocations (one using Clang infrastructure and the other not) meanwhile XL C/C++ for Linux (little endian) offers only one invocation that uses the Clang infrastructure. A non-Clang invocation was never offered for this Linux little endian edition. A non-Clang XL C/C++ for Linux was offered in XL C/C++ for Linux (big endian), and when the new little endian compilers came out, it was a good opportunity to start fresh with the new Clang infrastructure.

AIX users requiring binary compatibility can continue to use xlc (the non-Clang invocation). At this time, the Clang-based compiler offered in XL C/C++ for Linux (little endian) can only be invoked as xlc, not xlclang. This may change in the future.

assigned to @chuck.atkins

@trudeaun thanks for the explanation. Should we then use the XLClang compiler id for the little-endian Linux case too? Doing so will assume that if xlclang is added there it will only be for naming consistency but otherwise be identical to xlc.

Using XLClang on little-endian Linux now may affect the behaviour of existing CMake-based builds. Some form of that compiler product has been available for years. Philosophically, it is an XLClang compiler (closer to xlclang++ on AIX than to xlC on AIX). A new toolset definition was produced for Boost.Build at the time, but not CMake.

We've used a policy before to change the compiler id, e.g. CMP0025 to introduce AppleClang. Or, we could consider keeping XL for everything if we can because it does share the same version numbering (unlike the Clang/AppleClang case), but we would still need a way to know which one is actually running.

A new compiler ID seems appropriate. A policy sounds like a useful migration method.

OTOH a policy may be overkill. The Clang-based XL tools have not been out very long. The version numbering is the same so CMAKE_CXX_COMPILER_VERSION will be the same between both ids. User code that does if(CMAKE_CXX_COMPILER_ID STREQUAL "XL") can easily be changed to if(CMAKE_CXX_COMPILER_ID MATCHES "XL") to work with both.

mentioned in merge request !2921 (merged)

I think I see what you mean. Anyone with a working CMake build today can have the same CMake build by applying the change you suggested. The disadvantage is that, lacking a policy, the build may change silently. The Clang-based XL tools on Linux have been out since late 2014, so I would lean towards using a policy (at least for the Linux detection).

changed milestone to %3.15.0

closed via merge request !2921 (merged)

@brad.king Hi Brad, any chance this made it into 3.15? I saw 3.15 was just released. I was wondering if there might be a doc refresh to update https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_ID.html to include the new compiler id.

@trudeaun it is in 3.15 and is mentioned in the release notes. Documentation on the page you linked was accidentally left out. Fixed in !3430 (merged).

Just an fyi, pulled down latest stable release, 3.15.2, and have xlC/C++ 16.1.0.1 and out of the box bootstrap does not work for cmake. I made the changes noted in issue 18460 and then ran into a c++ comment line in a c file that the compiler did not like (Source/kwsys/ProcessUNIX.c", line 479). Fixed this and bootstrap continued and finished; was able to build cmake fine from this point on. Thanks

mentioned in merge request !3430 (merged)