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)
Related
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.
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've recently downloaded CUDA 7 and set it up to work with my project. On Mac, CUDA 7 requires clang to be the host compiler.
Now, I'm using a number of C++11 features. I've enabled these with -std=c++11 passed to nvcc this works. However, if I pass -Xcompiler -std=c++11 to nvcc, I get the following error regardless of if I also passed -std=c++11 by itself. The error is:
"invalid argument '-std=c++11' not allowed with 'C/ObjC'"
It seems like this should work, it certainly does with GCC. Anyone have a workaround. Otherwise, I'll file a bug report with Nvidia.
nvcc -dryrun ... will show what commands nvcc will execute. I don't currently have access to CUDA 7, only 6.5, but mine issues, among other things, two commands that compiles generated C source. This code generated by cudafe and have to be compiled by C compiler, but -Xcompiler adds options for both C and C++ modes.
I guess difference with my gcc situation is that I'm getting a warning while you have an error (this is exactly how gcc and clang differs in that case). For both compilers I don't see any way to suppress it, so I guess you have to fix your .cmake files to omit -Xcompiler options. This options shouldn't be used for language standard, just some very compiler-specific things.
Of course it doesn't work. You are specifying C++ options while using a C or Objective-C compiler. The source files must be C++ or Objective-C++.
I followed instructions at http://clang.llvm.org/get_started.html
I compiled latest trunk of llvm and clang with MSVC 2010. Now I can compile simple programs with Clang but when I tried to compile this program I got a lot of errors.
Here is program:
#include <algorithm>
int main(){ return 0; }
And here are some of errors:
In file included from hello.cpp:1:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\algorithm:6:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\memory:987:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\intrin.h:24:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\immintrin.h:32:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\xmmintrin.h:988:
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1384:22: error: expected expression
return (__m128)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1390:23: error: expected expression
return (__m128i)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1396:23: error: expected expression
return (__m128d)__in;
^
Complete output from Clang: http://pastebin.com/qi87K8qr
Clang tries to use MSVC headers but it doesn't work. Maybe I should use libc++ or libstdc++ instead, but how to do that?
Note I'm not interested in precompiled clang binaries
Yes, clang simply does not support all of Microsoft's extended C++ syntax, and therefore cannot parse Microsoft's C++ headers which use that syntax. Not only that but Clang also doesn't have complete support for Microsoft's C++ ABI, name mangling, etc. I believe Clang on Windows works alright with C, however.
To use a different C++ standard library instead you can make clang ignore the normal header and library directories with, IIRC, -nostdinc++ and -nostdlib++. Then you can tell clang the include and library directories you want to use (using -isystem or -I or whatever). However I'm not sure whether libc++ or libstdc++ work under those circumstances, since they probably depend on things that the Windows C runtime library does not have.
Chandler Carruth mentioned at Going Native 2013 that there are now alpha builds of clang for Windows with Visual Studio integration. Lots of stuff is broken, for example, streams (so good old hello world won't work). However, there is a lot of effort being put into making clang work on Windows, so expect it to get pretty good pretty fast.
Errors were in the header supplied with clang itself. Looks like it can't handle MMX/SSE types properly. Try to add -msse -msse2 switches to the command line.
I'm using libstdc++ and built clang using VS2012Express for desktop. The cmake string was "Visual Studio 11 Win64" and the essential dirs. are specified using -I argument.
My guess you program could work if I used mingw headers for Windows.
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.