I use a 3rd party project, that produces huge amount of warnings. I disable all of them in VS project properties. Sometimes, I switch to LLVM clang-cl toolset to check for warnings from clang. The 3rd party project produces so many warnings with clang-cl that VS is chocking with the amount of output.
I know how to disable them, I do so through command line args, for example: Wno-int-conversion -Wno-shift-op-parentheses etc. The problem, however, when I switch back to VS toolset, all of these command line params to disable warnings from clang-cl become errors (unknown cmd line args) with MS compiler.
Is there a way to have both clang and VS settings in the same VS project? Maybe, somehow conditional on ClangCL toolset these could be added only for clang-cl builds?
The first thing I tried worked right away, in case if anybody needs to solve the same problem:
<AdditionalOptions Condition="'$(PlatformToolset)'!='ClangCL'">/w24003 /w24005 ... %(AdditionalOptions)</AdditionalOptions>
<AdditionalOptions Condition="'$(PlatformToolset)'=='ClangCL'">-Wno-unknown-pragmas -Wno-unused-variable ... %(AdditionalOptions)</AdditionalOptions>
This way, with using LLVM clang-cl toolset with VS only clang cpecific command line params applies, and when using ms compiler, only ms compiler specific options are applied.
Related
I am trying to build my project and run an executable in a different machine where I can see thread related issues (if exist). I am using VS2019 and providing -fsanitize=thread -fPIE -pie -g options in the Configuration Properties->Debugging->Command Arguments.
When I run the .exe file, I don't see any generated file which I suppose should have been generated.
Am I providing wrong arguments to the compiler or what is wrong here?
Configuration Properties->Debugging->Command Arguments is a wrong place for compiler options. They should go to Configuration Properties->C/C++->Command Line->Additional options
These options you want to pass are not supported neither by MSVC compiler (Visual C++), nor by clang-cl (Clang under Windows that mimic MSVC)
MSVC does not have ThreadSanitizer at all. (-fsanitize=address is available though)
I have a C++ project which uses CMake as its build system in Visual Studio 2017 Enterprise. According to the documentation, I have to link using /LTCG and /GENPROFILE. In CMake, this seems to equate to setting the variable CMAKE_EXE_LINKER_FLAGS:
set(LINKER_FLAGS, "/LTCG /GENPROFILE")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${LINKER_FLAGS}")
Furthermore, since my application requires command line arguments, I had to define them in the launch.vs.json as seen in this answer.
Now if I run the application's x64-Release profile, it successfully completes in a normal, non-delayed Release build fashion. No .pgd has been generated which means that my passed linker flags probably have been ignored.
Another try was adding additional CMake linker flag variables:
set(LINKER_FLAGS, "/LTCG /USEPROFILE")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${LINKER_FLAGS}")
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} ${LINKER_FLAGS}")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${LINKER_FLAGS}")
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} ${LINKER_FLAGS}")
This also didn't work. Specifying /USEPROFILE afterwards did not generate a different binary. Also, the runtimes are roughly equivalent. There is also no indication on the command line that a profile has been generated or used.
What am I doing wrong here?
I am getting error
Error C1007 unrecognized flag '-Ot' in 'p2'
but unable to find -Ot in the command line string of the project. Googling did not help. Anyone know what does that flag stand for ?
I had a similar issue on a project that I was compiling. It seems to be caused when MSVC 2017 linker tries to link a dependency library ".lib" to your project and it was compiled with Optimization flag /Ot enabled. That is why you can not see it on command line of your own project. You can try one of these actions.
Recompile your libs without /Ot enabled (Properties → C/C++ → Optimization → Favor Size or Speed → Neither), then recompile whole project.
Update MSVC 2017 toolchain to the latest one, which should be 14.14.26428. After updating, recompile your project. It is strange, but in my machine configuration, toolchain 14.13 couldn't link libraries compiled with newer toolchains and /Ot enabled.
Both solutions worked in my case, but I ended up using number 2.
Just for future reference to this error msg:
I got this error with no -Ot option set, the error message was misleading. Turned out that I tried to build a project with a 140 toolset (VS2015 - forgot to upgrade to 141) with .dll and .lib dependencies already built with 141 (VS2017). After updating the toolset to 141 the project could be built.
You should find this flag in the Optimization property page of your project.
-Ot (/Ot) option is the Favor Fast Code flag (Attempts to offer improvements in execution time over space)
According to the Microsoft Visual C++ Documentation (https://learn.microsoft.com/en-us/cpp/build/reference/os-ot-favor-small-code-favor-fast-code),
If you use /Os or /Ot, then you must also specify /Og to optimize the
code.
Happened to me while building nmap. Executables did not have /GL, while libnetutil did. Removing /GL from libnetutil fixed it. Or, if possible (and desired), align /GL to all dependent targets (lib, dll/exe).
The official LLVM 4.0 build for Windows integrates with Visual Studio up to Visual Studio 2015. Unfortunately it still doesn't support Visual Studio 2017.
When you try to set the Platform Toolset of a project to LLVM-vs2014, it pops up an error.
Do you know any way to make it work?
Update
In 2018, LLVM 6.0 officially still doesn't support integration with Visual Studio 2017 (version 15.X.X), only with the Visual Studio 2015 (version 14.X.X) toolset.
It requires some msbuild targets that only ship with the C++ v140 toolset, and VS 2017 only installs the v141 toolset by default. If you open the VS 2017 installer, find the checkbox for the v140 toolset and install that then the right C++ msbuild targets will be available and the thing will work.
Finally, I found a brilliant GitHub repo with the required MSBuild platform toolsets which integrates LLVM clang 5.0.0 into Visual Studio 2017. After following the instructions of the README file, you will have two new platform toolsets LLVM-vs2017 and LLVM-vs2017_xp. Problem solved.
Update
I made a fork which is updated for LLVM 6.0.0 and provides better integration by providing include and library paths of LLVM/clang.
Thanks to Royi, who realized that the original .prop files are explicitly tailored for LLVM 5.0 and it misses adding the proper lib (
$(LLVMInstallDir)\lib) and include ($(LLVMInstallDir)\lib\clang\6.0.0\include) folders.
The LLVM project now explicitly supports Visual Studio 2017 via https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain
I'm a newbie with the LLVM technology and I'm using a Visual Studio extension, Clang Power Tools. They have a settings page from where you can install LLVM (all versions >= 4.0). After that you are free to apply clang compile or tidy with code modernization(this is what I appreciate the most) by using the extension buttons from VS toolbar. In this way you don't need to configure anything.
Update
Open the extension settings and select the LLVM page from the top. On the LLVM page, you'll see all the supported LLVM versions and at the right of each version the install button. Install any version you need. On the bottom of the page is a dropdown that allows you to select what version to use in case you installed multiple versions.
The feature is explained step by step in this blog post
LLVM/Clang now has an updated patch that allows you to use it with VS2017. But they still don't directly support VS2017. I asked on the LLVM developer mailing list for them to update their support for VS2017, so hopefully they'll do it. If they listen to what I said.
I have figured out how to integrate LLVM Clang 7.0 with Visual Studio 2017 update 15.5.6. v1913 with full support for PDB based debugging using the latest LLVM builds.
i.e., lld-link /DEBUG:GHASH; clang-cl -mllvm -emit-codeview-ghash-section flag to clang-cl.
It is a three step process.
Install latest llvm
Update the toolset.props, toolset.targets in VS to support latest clang
Select the new toolset to use for building your C/C++ or other lang project
As of Visual Studio 2017 update 15.4.5 the Microsoft "experimental" Clang C2 no longer works. Thus, the above fixes are necessary to use clang to compile code that has full PDB (not just CodeView /Z7 limited) debuggability. This also now becomes a more complete suite for portability testing cross-platform builds since you can build and PDB debug for windows using all LLVM components from the clang compiler front end to the LLVM codegen backend and LLVM linker.
Cheers, David
Check out January 09, 2018 http://planet.clang.org/
Look at the "Try it out!" section:
If you're already using clang-cl and lld-link on Windows today, you can try this out. There are two flags needed to enable this, one for the compiler and one for the linker:
To enable the emission of a .debug$H section by the compiler, you will need to pass the undocumented -mllvm -emit-codeview-ghash-section flag to clang-cl (this flag should go away in the future, once this is considered stable and good enough to be turned on by default).
To tell lld-link to use this information, you will need to pass the /DEBUG:GHASH to lld.
You just need to pass the -mllvm -emit-codeview-ghash-section flags in either your c++ projects "Command Line:Additional Options" area, or place them directly in the "toolset.props" file that you created in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\LLVM-vs2017 or
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Platforms\x64\PlatformToolsets\LLVM-vs2017.
The key is that in adding those cli options you're telling clang to emit debug information that the lld (aka lld-link) will understand and use to produce fully populated PDB files. Not the limited ones it made prior to the Jan 09, 2018 drops of LLVM 7.0.
toolset.targets: (any version)
<Project ToolsVersion="14.1"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(VCTargetsPath)\Microsoft.CppCommon.targets" />
</Project>
toolset.props: (Win32 version)
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Microsoft.Cpp.$(Platform).v141.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Microsoft.Cpp.$(Platform).v141.props')"/>
<Import Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Toolset.props" Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\v141\Toolset.props')"/>
<PropertyGroup>
<LLVMInstallDir>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\LLVM\LLVM)</LLVMInstallDir>
<LLVMInstallDir Condition="'$(LLVMInstallDir)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LLVM\LLVM)</LLVMInstallDir>
<ExecutablePath>$(LLVMInstallDir)\msbuild-bin;$(ExecutablePath)</ExecutablePath>
<LibraryPath>$(LLVMInstallDir)\lib\clang\7.0\lib\windows;$(LibraryPath)</LibraryPath>
</PropertyGroup>
<ItemDefinitionGroup>
<ClCompile>
<!-- remove the implicit vcxxx.pdb path to avoid rebuilds every time as clang-cl only supports /Z7 -->
<ProgramDataBaseFileName></ProgramDataBaseFileName>
<!-- Set the value of _MSC_VER to claim for compatibility -->
<AdditionalOptions>-m32 -fmsc-version=1913 %(AdditionalOptions)</AdditionalOptions>
</ClCompile>
</ItemDefinitionGroup>
</Project>
For x64, change -m32 to -m64
p.p.s., I have also enabled Microsofts ARM and ARM64 compilers for building native Windows-10-ARM apps (not UWP modern-com-junk). But, as yet, I have not done enough digging through the clang sources to properly configure something similar for ARM to what -m32 and -m64 do for Intel code-gen.
See these articles:
http://pete.akeo.ie/2017/05/compiling-desktop-arm-applications-with.html
https://www.theverge.com/2017/12/5/16737288/microsoft-windows-10-qualcomm-arm-laptops-launch
https://wiki.winehq.org/ARM
I want to write parallel program in C++ using OpenMP, so I am getting started with OpenMP.
On the other words I am a beginner and I need good OpenMP guide telling how to install it.
Does someone know how to install OpenMP on Windows, then compile and run the program?
OpenMP is not something that you install. It comes with your compiler. You just need a decent compiler that supports OpenMP and you need to know how to enable OpenMP support since it is usually disabled by default.
The standard compiler for Windows comes from Microsoft and it is the Microsoft Visual C/C++ compiler from Visual Studio. Unfortunately its OpenMP support is a bit outdated - even the latest and greatest Visual Studio only supports OpenMP 2.0 (an outdated standard version from 2002). See here for more information on how to use OpenMP in Visual Studio. There are other compilers available as well - both Intel C/C++ Compiler (commercial license required) and GCC (freely available) support newer OpenMP versions and other compilers are available too.
You can start learning OpenMP by visiting the OpenMP web site here. Also there is a great tutorial on OpenMP from Lawrence Livermore National Laboratory available here.
2020 Update: Microsoft now ships Clang for Windows with Visual Studio. Although it is a bit convoluted, one can (ab)use the Clang-cl toolset to produce working 32-bit OpenMP programs. A number of steps are necessary:
If not already installed, add Clang and Clang-cl using the Visual Studio 2019 Installer.
Set the project's platform toolset (project Properties -> General -> Platform Toolset) to "LLVM (clang-cl)".
Enable Clang OpenMP support by adding -Xclang -fopenmp to the compiler options in project Properties -> C/C++ -> All Options -> Additional Options.Important: make sure that OpenMP support is disabled before switching the platform toolset (this is the default for new C++ projects). It seems that VS remembers the setting and still passes /openmp even though the language configuration for Clang has no option for OpenMP. If clang-cl.exe throws error MSB8055 (unsupported /openmp option) during build, set the platform toolset back to "Visual Studio 2019 (vXXX)" and disable the OpenMP support in Properties -> C/C++ -> Language -> Open MP Support, then switch the platform toolset again to "LLVM (Clang-cl)".
Add libomp.lib to the additional libraries in project Properties -> Linker -> Input -> Additional Dependencies.
Add the path to libomp.lib to the linker search path by adding a new entry with value $(LLVMInstallDir)\lib in project Properties -> Linker -> General -> Additional Library Directories.
Add a post-build action that copies LLVM's libomp.dll to the project output directory (without this step, running the executable will fail unless libomp.dll is in the DLL search path). In project Properties -> Build Events -> Post-Build Event -> Command Line:
xcopy /y "$(LLVMInstallDir)\bin\libomp.dll" "$(SolutionDir)$(Configuration)"
Build and run the project.
Note: this is very much likely still unsupported by Microsoft and it only works for x86 projects since the LLVM libraries shipped with VS are 32-bit only.
So here is what I did to finally get OpenMP working on my Windows 10 PC:
Get MinGW - Download and grab what you need to get the basic gcc compiler and the g++ pakage (its really easy to do). You can always run g++ -v to make sure it is up and running
Run mingw-get upgrade --recursive "gcc<4.7.*" "gcc-g++<4.7.*" This is the "Fun" part. Because at this time there was no libgomp library supported in their 4.9.* version my gcc wasn't able to recognize <omp.h> the last support version was 4.7.2 so with this I finally was able to run my openMP
To compile run g++ -fopenmp myOpenMPFile.cpp -o myOpenMP and it will all work from there
gcc -fopenmp myOpenMPFile.cpp -o myOpenMP will also work for C code
I would like to share what I did to get OpenMP working on my Windows 10 PC (things have got even simpler in 2019)
I installed MinGW distribution from here with GCC 8.2.0 compiler. The maintainer of the distribution has already added winpthreads and OpenMP support to GCC.
I compiled my code with -fopenmp flag as follows: g++ -fopenmp main.cpp -o exec
Note: the MinGW distribution provides support for many useful libraries (such as Boost 1.69.0) and other utilities. I found it to be very useful.