GCC Cling compile with -std=c++17 still contains -std=c++11

[geneweber]

Hi,

I’m compiling Cling 1.0~dev with GCC 9.4.0 on Ubuntu 20.04.1. I decided to re-compile it using -std=c++17. The cmake line I’m using is:

cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 -DCMAKE_CXX_FLAGS='-std=c++17' -DLLVM_BUILD_TOOLS=Off  -DPYTHON_EXECUTABLE=/usr/bin/python3 ../src 2>&1 | tee cmake.log

The CMakeOutput.log file shows numerous compile lines that contain both -std=c++17 and -std=c++11 such as:

/usr/bin/c++    -std=c++17 -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 .....

I’ve searched through cmake source files trying to understand why this is happening, and even changed every occurrence of c++11 and CXX11 I found and reran cmake, but the result is the same.

Help / insights appreciated.

Thanks,

Gene

[Axel]

Thanks Gene, that’s indeed “weird” on LLVM’s side. They seem to use LLVM_CXX_STD instead of CMAKE_CXX_STANDARD. So you probably need to configure with -DLLVM_CXX_STD=c++17.

Thanks for bringing this up, we also need to fix this on the ROOT side

Axel

[geneweber]

Thanks Axel,

Changing -DCMAKE_CXX_STANDARD=17 to -DLLVM_CXX_STD=17 results in the following cmake error.

CMake Error at cmake/modules/HandleLLVMOptions.cmake:462 (message):
  The host compiler does not support '-std=17'.

Interestingly using -DCMAKE_CXX_STANDARD=14 or -DCMAKE_CXX_STANDARD=11 produces the exact same error for those standards.

While reading the cmake code to try and understand this error I realized that if it’s been too long since I’ve had a headache, all I need to do is read cmake code.

So I just searched for c++11 in cmake files and found/replaced it in:

• src/tools/cling/CMakeLists.txt
• src/cmake/modules/HandleLLVMOptions.cmake
• src/cmake/modules/CheckAtomic.cmake
• src/cmake/modules/AddLLVM.cmake

This reduced, but did not eliminate the occurrence of -std-c++11 on the compile lines shown in obj/CMakeFiles/CMakeOutput.log

-DCMAKE_CXX_FLAGS=’-std=c++17’ simply adds an additional -std=c++17 at the beginning of each compile line, so it’s not really valuable since the compile lines don’t lack for -std= flags.

It’s obvious that the author of the cmake code wanted to ensure c++11. Perhaps c++17 is not viable?

Best,

Gene

[Wile_E_Coyote]

-DLLVM_CXX_STD=c++17

[bellenot]

In LLVM there is LLVM_CXX_STD, which should be either c++1y or c++1z, and LLVM_ENABLE_CXX1Y or LLVM_ENABLE_CXX1Z options (bool). In ROOT they are all automatically set by the CMAKE_CXX_STANDARD option. Maybe changing the option on an existing build could mix those values, and re-configuring from scratch could fix the issue. I can try to check how it works in stand-alone cling on Friday.
P.S. If you open a cmake-gui you can see those options

[Wile_E_Coyote]

What you say is that one should use a deprecated "c++1z" ("c++1y") name instead of "c++17" ("c++14").

[bellenot]

I simply show the options available in LLVM (which is old) that are automatically set when building ROOT

[Axel]

@bellenot also cxx17 etc are supported - they just don’t have even more dedicated funny LLVM CMake variables but are simply covered by LLVM_CXX_STD. See my PR - it does what you’d expect it to do.

[geneweber]

Thanks.

Running:

cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_TOOLS=Off -DPYTHON_EXECUTABLE=/usr/bin/python3

Some /usr/bin/c++ lines in CMakeOutput.log and CMakeError.log have -std=c++11, and some have no “-std=”.

Running:

cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_CXX_STD=c++17 -DLLVM_BUILD_TOOLS=Off -DPYTHON_EXECUTABLE=/usr/bin/python3

Some /usr/bin/c++ lines in CMakeOutput.log and CMakeError.log have only -std=c++11, some have only -std=c++17, some have both, and some have no “-std=”.

CMakeOutput.log and CMakeError.log from this second run are attached.

Best,

Gene
CMakeError.txt (37.0 KB)
CMakeOutput.txt (153.7 KB)