CLion 2020.1 EAP: CUDA Support & Clang on Windows

Posted on by Anastasia Kazakova

CLion started the 2020.1 EAP program last week with many improvements to Clang-based tooling, the debugger, and the overall editor. This week a new build is available, bringing more sophisticated CUDA support!

You can download the build (201.4865.10) from our website, via the Toolbox App, or as a snap package (for Ubuntu) and install it side by side with the stable release build.

DOWNLOAD CLION 2020.1 EAP

CUDA support

Why CUDA?

Before jumping into a detailed overview of what’s actually supported for CUDA, let me first briefly elaborate on how we have come to this decision. If you are not really interested in this, feel free to skip directly to the next part.

CLion is a general-purpose cross-platform C and C++ IDE. There are plenty of interesting domains where C and C++ are used as the primary language. A number of global industries, like High-frequency trading (HFT), embedded development, and game development, use C and C++, along with other more specific fields like automated vehicle research, AI, telecommunications, and GPGPU. Because of the limited number of developers we have in the team, it’s hard to cover each and every one of these areas right now. (Believe us, we’d love too!) So we have had to make some difficult choices about what to prioritize.

That’s why we recently analyzed the current state of CLion’s support for various C++ development areas. The main criterion we considered was whether users were able to expect their code to be correctly handled by the IDE, at least from the general C++ perspective. And once that was determined, more specific requests would come into play.

With this framework to guide us, in November 2019 we took a look at various areas where CLion was still weak and realized that CUDA was one where we generally failed to meet our criterion. Taking Qt as a point of contrast, CLion can successfully parse and work with a Qt project. Some Qt specifics might not be taken into account in the refactorings, code generation, and other smart actions, but from a C++ language perspective, they are still correct. With CUDA the situation was different. CUDA C and C++ is essentially C/C++ with a few extensions, and the IDE was not handling these extensions correctly. This resulted in red code, false positives, and other unpleasant consequences that you could encounter as soon as you started using CUDA in CLion, making the IDE completely impossible to use.

That’s why we’ve decided to dedicate some time to fixing these issues with CUDA. Of course, more specific support for specific technologies, be they CUDA, Qt, or others, is also on our roadmap for the future. But for now, our goal is to eliminate the most irritating issues.

Start a new project with CUDA

If you are new to CUDA, we recommend starting by downloading the CUDA Toolkit from the official site and checking out the official documentation. To start a new project in CLion, call File | New Project and select CUDA library or CUDA executable:
New CUDA project

The sample CMake and main.cu files will be generated for you:
new CUDA project CMake

You may notice new file extensions for source and header CUDA files – .cu/.cuh. They are also available in the new C/C++ file creation dialog and have their own icons:
CUDA files

For CUDA projects, the list of CMake targets in this dialog includes general CMake and CUDA targets (created with cuda_add_executable/cuda_add_library).

How does CLion support CUDA?

Let’s clone the ClaraGenomicsAnalysis project from GitHub and check out what CLion is capable of in terms of CUDA support. Make sure CMake used in CLion knows where to find the CUDA toolchain. For example, you can set CMAKE_CUDA_COMPILER to the nvcc compiler path.

The first thing you’ll notice is that CUDA code, including all CUDA specific extensions, is now parsed and highlighted correctly:
CUDA prj sample

This means code navigation, code documentation, and other code assistance actions work:
Quick Documentation

Additionally, CLion can complete angle brackets for kernel calls:
CUDA completion

Known issues and limitations

First of all, there are some OS-specific details you’ll need to pay close attention to:

  • On Windows: CUDA only works with the Microsoft Visual C++ toolchain, and you are required to have x64 cl.exe in your PATH. For this toolchain, CLion bundles the LLDB-based debugger developed by JetBrains, which for the moment might have issues with the CUDA code.
  • On Linux: Because of the regression, cuda-gdb can’t be selected in the UI (CPP-18931).
  • On macOS: We didn’t test on this platform, as it’s officially no longer supported after v10.13.

Other notable issues for CUDA code include:

  • Code insight actions (like Go to Declaration, Rename, or Extract Variable) don’t work inside <<<...>>> (CPP-18722).
  • Coverage, cuda-memcheck, Valgrind Memcheck, and Profiling don’t work properly for CUDA projects, for now at least. This is definitely a feature we are considering to address in future updates.

Clang on Windows

While Clang has been available in CLion on Linux and macOS for quite a long time, certain issues and limitations made it too inconvenient to be practical on Windows. We have now made it possible to use clang-cl in CLion on Windows! All versions from 8.0 on are supported.

You can install it from the LLVM site or along with the Visual Studio tools. When done, select the Visual Studio toolchain in CLion and point to clang-cl.exe in the toolchain settings:
Clang-cl

You are now all set up!

Mind you, there is a known issue that causes -T clangcl options not to be picked up by CLion if the bundled CMake is in use while Visual Studio is enabled (CPP-18848).

If you want to find out more, the full release notes are available here.

DOWNLOAD CLION 2020.1 EAP

Your CLion team
JetBrains
The Drive to Develop

Comments below can no longer be edited.

36 Responses to CLion 2020.1 EAP: CUDA Support & Clang on Windows

  1. Ricardo Maltez says:

    February 5, 2020

    Hi!
    First of all thank you for keeping improving the Clion!
    I would like to request to take the time to look into this issue:
    https://youtrack.jetbrains.com/issue/CPP-5102

    In the codebase that I work on all the functions are “noexcept” so when I try to override any function using the amazing auto override feature of Clion I have to correct the function declaration and implementation to include the “noexcept” keyword.

    This would really improve my daily work and probably the work of other developers 🙂

    • Anastasia Kazakova says:

      February 5, 2020

      Thanks, we’ll check

      • Ricardo Maltez says:

        February 5, 2020

        Great!
        Thanks! 😀

  2. Fernando Rodriguez says:

    February 6, 2020

    Try using clag-cl.exe and when loading CMAKE you get the error: — broken

    • Fernando Rodriguez says:

      February 6, 2020

      CMake Error at C:/Program Files/JetBrains/CLion 201.4515.29/bin/cmake/win/share/cmake-3.16/Modules/CMakeTestCXXCompiler.cmake:53 (message):
      The C++ compiler

      “C:/Program Files/LLVM/bin/clang-cl.exe”

      is not able to compile a simple test program.

      It fails with the following output:

      Change Dir: C:/git/AGENT/cmake-build-clang/CMakeFiles/CMakeTmp

      Run Build Command(s):C:/jom_1_1_2/jom.exe /nologo cmTC_59ce6\fast && jom: parallel job execution disabled for Makefile
      C:\jom_1_1_2\jom.exe -f CMakeFiles\cmTC_59ce6.dir\build.make /nologo -L CMakeFiles\cmTC_59ce6.dir\build
      Building CXX object CMakeFiles/cmTC_59ce6.dir/testCXXCompiler.cxx.obj
      C:\PROGRA~1\LLVM\bin\clang-cl.exe @C:\Users\DIEGO~1.ROD\AppData\Local\Temp\testCXXCompiler.cxx.obj.23876.0.jom
      Linking CXX executable cmTC_59ce6.exe
      “C:\Program Files\JetBrains\CLion 201.4515.29\bin\cmake\win\bin\cmake.exe” -E vs_link_exe –intdir=CMakeFiles\cmTC_59ce6.dir –rc=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\rc.exe –mt=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\mt.exe –manifests — C:\PROGRA~2\MICROS~4\2019\ENTERP~1\VC\Tools\Llvm\bin\lld-link.exe /nologo @CMakeFiles\cmTC_59ce6.dir\objects1.rsp @C:\Users\DIEGO~1.ROD\AppData\Local\Temp\cmTC_59ce6.exe.23876.125.jom
      LINK Pass 1: command “C:\PROGRA~2\MICROS~4\2019\ENTERP~1\VC\Tools\Llvm\bin\lld-link.exe /nologo @CMakeFiles\cmTC_59ce6.dir\objects1.rsp /out:cmTC_59ce6.exe /implib:cmTC_59ce6.lib /pdb:C:\git\AGENT\cmake-build-clang\CMakeFiles\CMakeTmp\cmTC_59ce6.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\cmTC_59ce6.dir/intermediate.manifest CMakeFiles\cmTC_59ce6.dir/manifest.res” failed (exit code 1) with the following output:
      lld-link: error: : undefined symbol: mainCRTStartup
      jom: C:\git\AGENT\cmake-build-clang\CMakeFiles\CMakeTmp\CMakeFiles\cmTC_59ce6.dir\build.make [cmTC_59ce6.exe] Error 2
      jom: C:\git\AGENT\cmake-build-clang\CMakeFiles\CMakeTmp\Makefile [cmTC_59ce6\fast] Error 2

      CMake will not be able to correctly generate this project.
      Call Stack (most recent call first):

      • Anastasia Kazakova says:

        February 6, 2020

        We’ll check the error and will be back to you soon

      • Ivan says:

        February 7, 2020

        Do you have the same bitness for your installed clang-cl and your Visual studio toolchain? If they match then please report a bug. You can also try to use another CMake generator like ninja for example.

  3. Helge Penne says:

    February 7, 2020

    We just ran into an incredibly confusing and dangerous problem with the “amend commit” feature:
    https://youtrack.jetbrains.com/issue/CPP-18991

    This can cause a lot of pain and confusion, and can cause unintentional and hidden changes to the user’s code base. The good news is that it should probably be an easy fix. Is there any chance of getting this fixed in the next release?

    • Anastasia Kazakova says:

      February 7, 2020

      Thanks for reporting, we’ll proceed in the ticket

      • Helge Penne says:

        February 11, 2020

        I see that this has been filed under IDEA-65263, which is probably correct. This bug is quite old. Is there any hope that you can get this fixed? It is important because the damage this can do to the user’s code base is very significant It should also be an easy fix.

        • Anastasia Kazakova says:

          February 11, 2020

          I see there is an ongoing discussion about the required fix. Let’s see where it goes in the ticket. And feel free to share your ideas and expectations there.

  4. Shawn Zhong says:

    February 9, 2020

    Hi, I am wondering if there is an option to disable CUDA support on Mac?

    Before upgrading to EAP, I rely on the CUDA header files for code completion. CLion treated .cu files as normal C++ files, and everything works smoothly (except that CLion complains about “<<>>”, but that’s fine for me).

    I upgraded to EAP yesterday and CLion seems to treat *.cu files as CUDA files. It throws tons of errors, complaining that it cannot find the definition of some symbols. So I have to downgrade it to the stable version.

    Note: I am not expected to compile CUDA projects on my Mac. I add the following lines on my CMakeLists.txt just for code completion and documents.

    add_definitions(-include cstdlib)
    add_definitions(-include ${CUDA_INCLUDE_DIR}/cuda_runtime_api.h)
    add_definitions(-include ${CUDA_INCLUDE_DIR}/device_launch_parameters.h)
    include_directories(SYSTEM ${CUDA_INCLUDE_DIR})
    
    • Anastasia Kazakova says:

      February 10, 2020

      > I am not expected to compile CUDA projects on my Mac.

      Is it not possible? Or are there CMake issues in your case?

    • Anastasia Kazakova says:

      February 10, 2020

      Wondering why it doesn’t work for you for 2020.1 EAP. Can you please create a ticket in https://youtrack.jetbrains.com/issues/CPP and add IDE logs there? We’ll start the investigation from there. And maybe you can provide a sample project to reproduce?

  5. Helge Penne says:

    February 10, 2020

    We ran into a bug with the Google Test integration when upgrading to the latest version of Google Test. It seems that CLion misinterprets the Google Test output of parameterized tests and terminates the test execution. The tests run just fine outside of CLion:
    https://youtrack.jetbrains.com/issue/CPP-18042

    Details have been added to the issue. Note that the title of the issue is perhaps a little misleading. This seems rather major to us, as it prevents us from using the latest Google Test version. We really hope you can fix this in the release you are working on.

    • Anastasia Kazakova says:

      February 10, 2020

      Thanks, we’ll investigate

    • Alexey Utkin says:

      February 10, 2020

      It seems the problem has been fixed in CLion 2020.1 EAP (https://youtrack.jetbrains.com/issue/CPP-16301) and backported to the CLion 2019.3.4 branch (but it has not yet been released).
      Could you make sure that the problem is fixed in CLion 2020.1 EAP?

      • Helge Penne says:

        February 11, 2020

        We’ve confirmed that this is indeed fixed in the latest EAP. Thank you!

        • Anastasia Kazakova says:

          February 11, 2020

          Glad to know that! Thanks.

  6. Nick says:

    February 22, 2020

    Hope the remote cuda code running and debuging could be kept in the macOS version! Appreciate with your best effort. Thank you!

    • Anastasia Kazakova says:

      February 22, 2020

      Thanks. Do you mean smth doesn’t work for you now there?

  7. mumin16 says:

    March 9, 2020

    clang snapshot install:
    https://llvm.org/builds/

    cmake options:
    -G “Visual Studio 16 2019” -T LLVM_v142

    toolchains:
    c compiler:
    C:\Program Files\LLVM\bin\clang.exe
    c++ compiler:
    C:\Program Files\LLVM\bin\clang++.exe

    • mumin16 says:

      March 9, 2020

      it works

  8. mumin16 says:

    March 9, 2020

    lldb not evulate all variables!

    • mumin16 says:

      March 9, 2020

      #include

      struct RGB{
      float Red{1},Green{0},Blue{0};
      }rgb;

      int main(int argc,char **argv) {
      auto[r,g,b]=rgb;

      return 0;
      }

      /*
      where are r,g,b?
      */

      • Anastasia Kazakova says:

        March 10, 2020

        Could you please specify:
        1) Where do you have the breakpoints set and at which line you are when expecting the r, g, b?
        2) Where do you expect/looking for the values? If you hover on the variable, will you see the value?

        Am I right it’s 2020.1 EAP build? Which macOS version are you at?

        • Anastasia Kazakova says:

          March 10, 2020

          Or is it a bundled LLDB-based debugger for MSVC toolchain?

          • mumin16 says:

            March 10, 2020

            it is MSVC toolchain

            • Anastasia Kazakova says:

              March 10, 2020

              Do you use Clang-cl as a compiler?

  9. mumin16 says:

    March 9, 2020

    Project with clang toolchain can’t turn to mingw toolchain! i deleted build directory , i reset cmake cache , i moved mingw to top in toolchains. But not work…

    • mumin16 says:

      March 10, 2020

      we must delete cmake options when we switch to mingw. Actually , each toolchains must have own cmake options.

      • Anastasia Kazakova says:

        March 10, 2020

        You have to do Tools | CMake | Resent Cache and reload project.
        If you simply update the toolchain, then the CMake Profile stays and you have to reset the cache and update it within the same CMake generation directory. If you want to have several, then create several CMake Profiles, each corresponding to its own toolchain.

  10. Rob says:

    March 9, 2020

    Remote Debug/Deploy to Ubuntu CUDA from Mac Catalina not working properly

    1) Remote Cmake deploys and run/debug works, not working well. IF we use standard cmake such as:

    cmake_minimum_required(VERSION 2.8)
    find_package(CUDA QUIET REQUIRED)
    set(CUDA_NVCC_FLAGS …)
    cuda_add_executable(…)

    2) If we try to do as suggested by this post as:
    cmake_minimum_required(VERSION 3.10)
    project(… CUDA)
    add_executable(… main.cu)

    We get CUDA errors, as below. I believe the IDE is trying to find CUDA locally on the MAC.

    CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
    Missing variable is:
    CMAKE_FIND_LIBRARY_PREFIXES
    CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
    Missing variable is:
    CMAKE_FIND_LIBRARY_SUFFIXES

    • Daniel Below says:

      March 10, 2020

      > I believe the IDE is trying to find CUDA locally on the MAC.

      We are aware of an issue where that is the case – feel free to follow CPP-18964 and/or CPP-19420 for further updates.

      > We get CUDA errors, as below.

      If you could attach a small reproducer to CPP-19420 it would be greatly appreciated.

  11. Daniil says:

    April 21, 2020

    For anyone who encounters this, I thought I’d share a solution here

    When using CLion with clang-cl.exe in Visual Studio toolchain you might want to enable exceptions (try catch blocks), because it is disabled by clang by default

    > error: cannot use ‘try’ with exceptions disabled

    Add in CMakeLists.txt
    add_compile_options(/EHsc)

    or if you don’t want to mess with the root CMakeLists file, then in Build, Execution, Deployment -> CMake -> Debug (or any other configuration)
    under CMake Options add -DCMAKE_CXX_FLAGS+=/EHsc

Subscribe

Subscribe for updates